from:"Stefan"



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19767:
--
  Fix Version/s: 4.1.6
 5.0-beta2
 5.1-alpha1
 (was: 5.x)
 (was: 4.1.x)
 (was: 5.0.x)
Source Control Link: 
https://github.com/apache/cassandra/commit/891e65e251d102d2664f84d22734b95235a7cb16
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.6, 5.0-beta2, 5.1-alpha1
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[vbox-dev] Windows arm64 support

2024-07-15 Thread Stefan Lugonjic via vbox-dev

Hi,

I am writing on behalf of my team from Endava company. Our task is to work with 
opensource community, and setup multiple applications for use on win11 arm64 
machines.
One of the tasks is to understand the problems and if possible work on build 
for Windows 11 arm64.
We've seen that there is already some effort invested in Darwin arm64, and we 
wanted to check if there are similar plans for supporting Windows arm64, and if 
we can somehow help with that work?

Stefan Lugonjic

The information in this email is confidential and may be legally privileged. It 
is intended solely for the addressee. Any opinions expressed are mine and do 
not necessarily represent the opinions of the Company. Emails are susceptible 
to interference. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on 
it, is strictly prohibited and may be unlawful. If you have received this 
message in error, do not open any attachments but please notify the Endava 
Service Desk on (+44 (0)870 423 0187), and delete this message from your 
system. The sender accepts no responsibility for information, errors or 
omissions in this email, or for its use or misuse, or for any act committed or 
omitted in connection with this communication. If in doubt, please verify the 
authenticity of the contents with the sender. Please rely on your own virus 
checkers as no responsibility is taken by the sender for any damage rising out 
of any bug or virus infection.

Endava plc is a company registered in England under company number 5722669 
whose registered office is at 125 Old Broad Street, London, EC2N 1AR, United 
Kingdom. Endava plc is the Endava group holding company and does not provide 
any services to clients. Each of Endava plc and its subsidiaries is a separate 
legal entity and has no liability for another such entity's acts or omissions.
___
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev

[jira] [Updated] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19767:
--
Status: In Progress  (was: Patch Available)

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19767:
--
Status: Review In Progress  (was: Patch Available)

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19767:
--
Status: Ready to Commit  (was: Review In Progress)

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19767:
--
Status: Patch Available  (was: In Progress)

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [PATCH v2 0/2] a little RPi watchdog cleanup


On 7/15/24 15:03, Rasmus Villemoes wrote:

Stefan Roese  writes:


@Tom,

I can't find these patches (and v1) in patchworks. Do you have an
idea, why this is the case?



Perhaps because they (v2) have already been merged to master via a PR from
Peter?  commit 1ca216522d4.


Ah, I was not aware that it was already merged. Okay, that explains it
of course.


So one has to change 'state' from 'action required' to see them:
https://patchwork.ozlabs.org/project/uboot/list/?series===*=hw_watchdog==


Nice, I never noticed that I could change this view.

Thanks,
Stefan

[jira] [Commented] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866049#comment-17866049
 ] 

Stefan Miklosovic commented on CASSANDRA-19767:
---

Brandon privately agreed with the above-mentioned approach as well.

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866048#comment-17866048
 ] 

Stefan Miklosovic commented on CASSANDRA-19767:
---

[https://github.com/apache/cassandra/pull/3422/files]

 

[~brandon.williams]  is this good enough for you? We do not need to change / 
reshuffle yaml on startup_checks. This pattern of marking some configuration 
properties as "complex options" is there a long time.

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [VOTE] Release httpd-2.4.62-rc1 as httpd-2.4.62

2024-07-15 Thread Stefan Eissing via dev




> Am 15.07.2024 um 14:13 schrieb Eric Covener :
> 
> Hi all,
> 
> Please find below the proposed release tarball and signatures:
> 
> https://dist.apache.org/repos/dist/dev/httpd/
> 
> I would like to call a VOTE over the next few days to release
> this candidate tarball httpd-2.4.62-rc1 as 2.4.62:
> [ ] +1: It's not just good, it's good enough!
> [ ] +0: Let's have a talk.
> [ ] -1: There's trouble in paradise. Here's what's wrong.
> 

+1, macOS 14.5, x86_64

Thanks for the hard work, Eric!

- Stefan

[jira] [Commented] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17866029#comment-17866029
 ] 

Stefan Miklosovic commented on CASSANDRA-19767:
---

Unfortunately, I am not sure this is what we want. The logic behind writing 
that documentation is that a respective user can just un-comment the whole 
block of the docs, tweak the values and it would just work. The way how 
startup_checks were treated here indeed fixes the rendering issue, but it 
becomes quite counter-intuitive for anybody who is modifying that file by hand 
as they would need to copy over whole configuration sections for respective 
configuration property.

I do not know what is the best to do there. I tried to play with the rendering 
but it does not do what I want.

One solution would be to move startup_checks to the very bottom of 
cassandra.yaml so it will not be merged together with 
storage_compatibility_mode.

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19767:
--
Status: Patch Available  (was: Ready to Commit)

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Please pull u-boot-marvell/master


Hi Tom,

please pull this small batch of Marvell related patches:


- mvebu: Migrate to upstream DT for Synology DS116 (Armada 385) board (Tony)
- mvebu: Enable bootstd and other modernization for Synology DS414 
(Armada XP) board (Tony)



Here the Azure build, without any issues:

https://dev.azure.com/sr0718/u-boot/_build/results?buildId=373=results

Thanks,
Stefan

The following changes since commit b182816c1fb436916661949213c543bf4d42250b:

  turris_1x: Normalize Kconfig usage (2024-07-13 10:42:15 -0600)

are available in the Git repository at:

  g...@source.denx.de:u-boot/custodians/u-boot-marvell.git

for you to fetch changes up to 51d4eb8bbaf35d14d4e30b885863ae00fbc47258:

  arm: mvebu: Enable bootstd and other modernization for Synology DS414 
(Armada XP) board (2024-07-15 08:42:04 +0200)



Tony Dinh (2):
  arm: dts: mvebu: Migrate to upstream DT for Synology DS116 
(Armada 385) board
  arm: mvebu: Enable bootstd and other modernization for Synology 
DS414 (Armada XP) board


 arch/arm/dts/Makefile  |   1 -
 arch/arm/dts/armada-385-synology-ds116.dts | 291 
-

 board/Synology/ds414/ds414.c   |  14 +-
 configs/ds116_defconfig|   3 +-
 configs/ds414_defconfig|  19 +-
 include/configs/ds414.h|  65 +--
 6 files changed, 63 insertions(+), 330 deletions(-)
 delete mode 100644 arch/arm/dts/armada-385-synology-ds116.dts

Re: [PATCH v3] arm: mvebu: Enable bootstd and other modernization for Synology DS414 (Armada XP) board


On 7/8/24 06:39, Tony Dinh wrote:

- Switch to standard boot (in include/configs/ds414.h and
configs/ds414_defconfig)
- Implement board_late_init() to ensure successful enumeration
of USB3 devices
- Remove unnecessary checkboard()
- Updated IDENT_STRING to indicate this u-boot supports both Synology
DS414 and DS214+ boards
- Add SYS_THUMB_BUILD to reduce binary size
- Add NET_RANDOM_ETHADDR
- Add CONFIG_LBA48 and CONFIG_SYS_64BIT_LBA to support >2TB HDD/SDD

Signed-off-by: Tony Dinh 


Applied to u-boot-marvell/master

Thanks,
Stefan


---

Changes in v3:
- Restore misc_init_r() to support booting legacy FW.
- Correct scripting error in EXTRA_ENV_SETTINGS_LEGACY in
/include/configs/ds414.h
- Remove CONFIG_PHY_ANEG_TIMEOUT from /include/configs/ds414.h. This symbol
has been moved to Kconfig.

Changes in v2:
- Define EXTRA_ENV_SETTINGS_LEGACY to restore default envs support for
booting legacy FW.

  board/Synology/ds414/ds414.c | 14 
  configs/ds414_defconfig  | 19 +--
  include/configs/ds414.h  | 65 +---
  3 files changed, 61 insertions(+), 37 deletions(-)

diff --git a/board/Synology/ds414/ds414.c b/board/Synology/ds414/ds414.c
index 8db810ad3e..1a4cea87e1 100644
--- a/board/Synology/ds414/ds414.c
+++ b/board/Synology/ds414/ds414.c
@@ -180,6 +180,13 @@ int board_init(void)
return 0;
  }
  
+int board_late_init(void)

+{
+   /* Do late init to ensure successful enumeration of XHCI devices */
+   pci_init();
+   return 0;
+}
+
  int misc_init_r(void)
  {
if (!env_get("ethaddr")) {
@@ -188,10 +195,3 @@ int misc_init_r(void)
}
return 0;
  }
-
-int checkboard(void)
-{
-   puts("Board: DS414\n");
-
-   return 0;
-}
diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
index 18c741d4f2..6391c43474 100644
--- a/configs/ds414_defconfig
+++ b/configs/ds414_defconfig
@@ -1,5 +1,6 @@
  CONFIG_ARM=y
  CONFIG_ARCH_CPU_INIT=y
+CONFIG_SYS_THUMB_BUILD=y
  CONFIG_ARCH_MVEBU=y
  CONFIG_SUPPORT_PASSING_ATAGS=y
  CONFIG_CMDLINE_TAG=y
@@ -25,44 +26,41 @@ CONFIG_SPL_BSS_MAX_SIZE=0x4000
  CONFIG_SPL=y
  CONFIG_DEBUG_UART_BASE=0xf1012000
  CONFIG_DEBUG_UART_CLOCK=25000
+CONFIG_IDENT_STRING="\nSynology DS214+/DS414 2/4-Bay Diskstation"
  CONFIG_SYS_LOAD_ADDR=0x80
  CONFIG_PCI=y
  CONFIG_DEBUG_UART=y
+CONFIG_BOOTSTD_FULL=y
  CONFIG_BOOTDELAY=3
  CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyS0,115200 ip=off initrd=0x840,8M root=/dev/md0 rw 
syno_hw_version=DS414r1 ihd_num=4 netif_num=2 flash_size=8 SataLedSpecial=1 
HddHotplug=1"
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="sf probe; sf read ${loadaddr} 0xd 0x2d; sf read 
${ramdisk_addr_r} 0x3a 0x43; bootm ${loadaddr} ${ramdisk_addr_r}"
  # CONFIG_DISPLAY_BOARDINFO is not set
  CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_BOARD_LATE_INIT=y
  CONFIG_MISC_INIT_R=y
  CONFIG_SPL_MAX_SIZE=0x1bfd0
  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
  # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
  CONFIG_SPL_I2C=y
+CONFIG_SYS_PROMPT="DS414> "
  CONFIG_SYS_MAXARGS=32
  CONFIG_CMD_I2C=y
  CONFIG_CMD_PCI=y
  CONFIG_CMD_SPI=y
  CONFIG_CMD_USB=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
  CONFIG_CMD_TFTPPUT=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
  CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_FAT=y
  CONFIG_CMD_JFFS2=y
  CONFIG_CMD_MTDPARTS=y
  CONFIG_CMD_UBI=y
-CONFIG_ISO_PARTITION=y
  CONFIG_ENV_OVERWRITE=y
  CONFIG_ENV_SPI_MAX_HZ=5000
  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
  CONFIG_ARP_TIMEOUT=200
  CONFIG_NET_RETRY_COUNT=50
+CONFIG_NET_RANDOM_ETHADDR=y
  CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_LBA48=y
+CONFIG_SYS_64BIT_LBA=y
  CONFIG_DM_I2C=y
  CONFIG_SYS_I2C_MVTWSI=y
  # CONFIG_MMC is not set
@@ -84,4 +82,3 @@ CONFIG_USB_XHCI_HCD=y
  # CONFIG_USB_XHCI_MVEBU is not set
  CONFIG_USB_XHCI_PCI=y
  CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_STORAGE=y
diff --git a/include/configs/ds414.h b/include/configs/ds414.h
index 6fbcec0898..9525657558 100644
--- a/include/configs/ds414.h
+++ b/include/configs/ds414.h
@@ -1,5 +1,6 @@
  /* SPDX-License-Identifier: GPL-2.0+ */
  /*
+ * Copyright (C) 2024 Tony Dinh 
   * Copyright (C) 2014 Stefan Roese 
   */
  
@@ -16,15 +17,8 @@

   * U-Boot into it.
   */
  
-/* I2C */

  #define CFG_I2C_MVTWSI_BASE0  MVEBU_TWSI_BASE
  
-/*

- * mv-common.h should be defined after CMD configs since it used them
- * to enable certain macros
- */
-#include "mv-common.h"
-
  /*
   * Memory layout while starting into the bin_hdr via the
   * BootROM:
@@ -38,21 +32,54 @@
   * L2 cache thus cannot be used.
   */
  
-/* SPL */

-/* Defines for SPL */
+/* Keep device tree and initrd in lower memory so the kernel can access them */
+#define RELOCATION_LIMITS_ENV_SETTINGS  \
+   "fdt_high=0x1000\0" \
+   "initrd_high=0x1000\0"
  
-/* Default Environment */

+/*
+ * mv-common.h should be defined after CMD configs since it used them
+

Re: [PATCH] arm: dts: mvebu: Migrate to upstream DT for Synology DS116 (Armada 385) board


On 5/22/24 23:51, Tony Dinh wrote:

Enable OF_UPSTREAM to use upstream DT and add marvell/ prefix to the
DEFAULT_DEVICE_TREE in DS116 defconfig. Remove current DTS in
arch/arm/dts/ directory.

Signed-off-by: Tony Dinh 


Applied to u-boot-marvell/master

Thanks,
Stefan


---

  arch/arm/dts/Makefile  |   1 -
  arch/arm/dts/armada-385-synology-ds116.dts | 291 -
  configs/ds116_defconfig|   3 +-
  3 files changed, 2 insertions(+), 293 deletions(-)
  delete mode 100644 arch/arm/dts/armada-385-synology-ds116.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a5c82ebf7a..75f7e616b4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -155,7 +155,6 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-385-atl-x530.dtb \
armada-385-atl-x530DP.dtb   \
armada-385-db-88f6820-amc.dtb   \
-   armada-385-synology-ds116.dtb   \
armada-385-thecus-n2350.dtb \
armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
diff --git a/arch/arm/dts/armada-385-synology-ds116.dts 
b/arch/arm/dts/armada-385-synology-ds116.dts
deleted file mode 100644
index 82a0373f7f..00
--- a/arch/arm/dts/armada-385-synology-ds116.dts
+++ /dev/null
@@ -1,291 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0 OR MIT)
-/*
- * Device Tree file for Synology DS116 NAS
- *
- * Copyright (C) 2017 Willy Tarreau 
- */
-
-/dts-v1/;
-#include "armada-385.dtsi"
-#include 
-
-/ {
-   model = "Synology DS116";
-   compatible = "marvell,a385-gp", "marvell,armada385", 
"marvell,armada380";
-
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-
-   memory {
-   device_type = "memory";
-   reg = <0x 0x4000>; /* 1 GB */
-   };
-
-   soc {
-   ranges = ;
-
-   internal-regs {
-   i2c@11000 {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   status = "okay";
-   clock-frequency = <10>;
-
-   eeprom@57 {
-   compatible = "atmel,24c64";
-   reg = <0x57>;
-   };
-   };
-
-   serial@12000 {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   status = "okay";
-   };
-
-   serial@12100 {
-   /* A PIC16F1829 is connected to uart1 at 9600 
bps,
-* and takes single-character orders :
-*   "1" : power off // already handled by the 
poweroff node
-*   "2" : short beep
-*   "3" : long beep
-*   "4" : turn the power LED ON
-*   "5" : flash the power LED
-*   "6" : turn the power LED OFF
-*   "7" : turn the status LED OFF
-*   "8" : turn the status LED ON
-*   "9" : flash the status LED
-*   "A" : flash the motherboard LED (D8)
-*   "B" : turn the motherboard LED OFF
-*   "C" : hard reset
-*/
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   status = "okay";
-   };
-
-   poweroff@12100 {
-   compatible = "synology,power-off";
-   reg = <0x12100 0x100>;
-   clocks = < 0>;
-   };
-
-   ethernet@7 {
-   pinctrl-names = "default";
-   phy = <>;
-   phy-mode = "sgmii";
-   buffer-manager = <>;
-   bm,pool-long = <0>;
-   status = "okay";
-   };
-
-   mdio@72004 {
-   pinctrl-names = "default&qu

[jira] [Updated] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19767:
--
Reviewers: Brandon Williams, Stefan Miklosovic
   Status: Review In Progress  (was: Patch Available)

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19767:
--
Status: Ready to Commit  (was: Review In Progress)

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-19767) Fix storage_compatibility_mode and startup_checks documentation



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19767:
--
Test and Documentation Plan: the docs render correctly
 Status: Patch Available  (was: In Progress)

> Fix storage_compatibility_mode and startup_checks documentation
> ---
>
> Key: CASSANDRA-19767
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19767
> Project: Cassandra
>  Issue Type: Task
>  Components: Documentation
>Reporter: Jackson Fleming
>Assignee: Jackson Fleming
>Priority: Normal
>  Labels: Documentation
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Attachments: image-2024-07-12-09-38-16-284.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The documentation for storage_compatibility_mode 
> ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode])
>  is very difficult to read. The below highlighted text seems incorrect.
> !image-2024-07-12-09-38-16-284.png|width=505,height=487!
>  
> It appears that the entry for the YAML option above it is causing entries to 
> get clobbered together (startup_checks)
>  
> This is actually a very useful and important feature for people upgrading to 
> Cassandra 5 to understand how to use properly - It would be good for it to be 
> easier to read, we should be encouraging use of the safest possible upgrade 
> path, which from my understanding would be:
> {{CASSANDRA_4 -> UPGRADING -> NONE}}
>  
>  
> Update - seems like the startup_checks docs is also missing in the 4.1 pages, 
> I'll fix that as well.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-19762) Implement dictionary lookup for CassandraPasswordValidator



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19762:
--
  Fix Version/s: 5.1-alpha1
 (was: 5.x)
Source Control Link: 
https://github.com/apache/cassandra/commit/98a0b54c4025ef21aa3fb56f1962c4771e095652
 Resolution: Fixed
 Status: Resolved  (was: Ready to Commit)

> Implement dictionary lookup for CassandraPasswordValidator
> --
>
> Key: CASSANDRA-19762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19762
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Core, Legacy/CQL
>    Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.1-alpha1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Updated] (CASSANDRA-19762) Implement dictionary lookup for CassandraPasswordValidator



 [ 
https://issues.apache.org/jira/browse/CASSANDRA-19762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Miklosovic updated CASSANDRA-19762:
--
Status: Ready to Commit  (was: Review In Progress)

> Implement dictionary lookup for CassandraPasswordValidator
> --
>
> Key: CASSANDRA-19762
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19762
> Project: Cassandra
>  Issue Type: New Feature
>  Components: Legacy/Core, Legacy/CQL
>    Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [PATCH v2 0/2] a little RPi watchdog cleanup


@Tom,

I can't find these patches (and v1) in patchworks. Do you have an
idea, why this is the case?

Thanks,
Stefan

On 7/12/24 11:07, Rasmus Villemoes wrote:

Two related leftovers I found while looking at remaining
hw_watchdog/CONFIG_HW_WATCHDOG items.

v2: Add Stefan's R-bs. Trim commit log in patch 1. No code changes.

CI: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=8910=results

I'm pretty sure the only failures are the false positive 'cyclic ...' ones.

Rasmus Villemoes (2):
   arm: bcm283x: remove unused empty hw_watchdog_disable
   board: rpi: remove leftover CONFIG_HW_WATCHDOG block

  arch/arm/mach-bcm283x/reset.c | 7 ++-
  board/raspberrypi/rpi/rpi.c   | 4 
  2 files changed, 2 insertions(+), 9 deletions(-)



Viele Grüße,
Stefan Roese

--
DENX Software Engineering GmbH,  Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

Hello new port requests

2024-07-14 Thread Stefan

Picocrypt

its already in the freebsd ports
https://cgit.freebsd.org/ports/tree/security/picocrypt

https://www.freshports.org/security/picocrypt/

https://github.com/Picocrypt


AES Crypt GUI
The GUI variant because the cli is already there
https://www.aescrypt.com/download/

Re: [weewx-user] Re: Biowetter and Pollen forecast in weewx-DWD

2024-07-14 Thread Stefan Gliessmann

Awesome!

Thank you!

I am updating weewx.conf as we are writting ;)

On Saturday, July 13, 2024 at 10:13:02 PM UTC+2 Karen K wrote:

> Some instructions:
>
>- Biowettervorhersage 
>
>- Pollenflugvorhersage 
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/8760e424-80de-4a6f-86d2-b3a8a7bdc35cn%40googlegroups.com.

[gcc r14-10416] s390: Fix output template for movv1qi

2024-07-13 Thread Stefan Schulze Frielinghaus via Gcc-cvs

https://gcc.gnu.org/g:5ade7afdefe7a5179c6a139103885c2cf911d9d0

commit r14-10416-g5ade7afdefe7a5179c6a139103885c2cf911d9d0
Author: Stefan Schulze Frielinghaus 
Date:   Sat Jul 13 08:01:59 2024 +0200

s390: Fix output template for movv1qi

Although for instructions MVI and MVIY it does not make a difference
whether the immediate is interpreted as signed or unsigned, GAS expects
unsigned immediates for instruction format SI_URD.

gcc/ChangeLog:

* config/s390/vector.md (mov): Fix output template for
movv1qi.

(cherry picked from commit e6680d3f392f7f7cc2a1515276213e21e9eeab1c)

Diff:
---
 gcc/config/s390/vector.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
index ed4742d93c91..7577f979243f 100644
--- a/gcc/config/s390/vector.md
+++ b/gcc/config/s390/vector.md
@@ -359,8 +359,8 @@
lr\t%0,%1
mvi\t%0,0
mviy\t%0,0
-   mvi\t%0,-1
-   mviy\t%0,-1
+   mvi\t%0,255
+   mviy\t%0,255
lhi\t%0,0
lhi\t%0,-1
llc\t%0,%1

[gcc r14-10415] s390: Align cjump_64 and icjump_64

2024-07-13 Thread Stefan Schulze Frielinghaus via Gcc-cvs

https://gcc.gnu.org/g:cd11413ff7c4353a3e336db415304f788d23a393

commit r14-10415-gcd11413ff7c4353a3e336db415304f788d23a393
Author: Stefan Schulze Frielinghaus 
Date:   Sat Jul 13 08:01:51 2024 +0200

s390: Align *cjump_64 and *icjump_64

During machine reorg we optimize backward jumps and transform insns as
e.g.

(jump_insn 118 117 119 (set (pc)
(if_then_else (ne (reg:CCRAW 33 %cc)
(const_int 8 [0x8]))
(label_ref 134)
(pc))) "dec_math_1.f90":204:8 discrim 1 2161 {*cjump_64}
 (expr_list:REG_DEAD (reg:CCRAW 33 %cc)
(int_list:REG_BR_PROB 719407028 (nil)))
 -> 134)

into

(jump_insn 118 117 432 (set (pc)
(if_then_else (ne (reg:CCRAW 33 %cc)
(const_int 8 [0x8]))
(pc)
(label_ref 433))) "dec_math_1.f90":204:8 discrim 1 -1
 (expr_list:REG_DEAD (reg:CCRAW 33 %cc)
(int_list:REG_BR_PROB 719407028 (nil)))
 -> 433)

The latter is not recognized anymore since *icjump_64 only matches
CC_REGNUM against zero.  Fixed by aligning *cjump_64 and *icjump_64.

gcc/ChangeLog:

* config/s390/s390.md (*icjump_64): Allow raw CC comparisons,
i.e., any constant integer between 0 and 15 for CC comparisons.

(cherry picked from commit 56de68aba6cb9cf3022d9e303eec6c6cdb49ad4d)

Diff:
---
 gcc/config/s390/s390.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index c607dce3cf0f..202aeb39d692 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -9526,7 +9526,8 @@
 (define_insn "*icjump_64"
   [(set (pc)
 (if_then_else
-  (match_operator 1 "s390_comparison" [(reg CC_REGNUM) (const_int 0)])
+  (match_operator 1 "s390_comparison" [(reg CC_REGNUM)
+  (match_operand 2 
"const_int_operand" "")])
   (pc)
   (label_ref (match_operand 0 "" ""]
   ""

Re: [Nut-upsuser] Eco Eclipse 1600 connects via USB put does not put out any data:

2024-07-12 Thread Stefan Schumacher via Nut-upsuser

Please ignore the last posting, I already found out that I had to
install pkg-config. Now usb-hid builds correctly and I will test it
tomorrow.

Cheers
Stefan

Am Fr., 12. Juli 2024 um 23:09 Uhr schrieb Stefan Schumacher
:
>
> Hi
> I have installed the following libraries in Debian 12.
>
> ii  libusb-0.1-4:amd64  2:0.1.12-32
>   amd64userspace USB programming library
> ii  libusb-1.0-0:amd64  2:1.0.26-1
>   amd64userspace USB programming library
> ii  libusb-1.0-0-dev:amd64  2:1.0.26-1
>   amd64userspace USB programming library development files
> ii  libusb-1.0-doc  2:1.0.26-1
>   all  documentation for userspace USB programming
>
> But when I try configure with :
> ./configure --with-libsystemd --with-user=nut --with-group=nut --with-usb
>
> I only get the following output. Do I need another version of libusb?
> Its version 1.0 and the dev files are there. Normally it should work,
> shouldn't it?
>
> configure: can not check libusb settings via pkg-config
> checking for libusb-config... no
> checking for libusb preferred version... none
> configure: WARNING: Defaulting libusb configuration
> checking for libusb cflags...
> checking for libusb ldflags... -lusb
> checking for usb.h... no
> checking for usb_init... no
> configure: error: USB drivers requested, but libusb not found.
>
>
> Yours
> Stefan
>
> Am Sa., 6. Juli 2024 um 19:57 Uhr schrieb Greg Troxel via Nut-upsuser
> :
> >
> > Stefan Schumacher via Nut-upsuser 
> > writes:
> >
> > > Thanks for the info. Nut runs on bare metal, there is no
> > > virtualization layer. I will have a look at the github post after
> > > writing this post. I have compiled and installed nut 2.8.2 as
> > > suggested. But now I am confused: Where is the usb-hid driver, which I
> > > used in Nut 2.8.0? Does one need to pass a special flag to configure
> > > to build it?
> >
> > My memory is that nut builds things if the prereqs are present.
> >
> > so
> >
> > ./configure --help
> >
> > and when you run configure, save stdout/stderr and read it.  especially
> > around building usb, and having the libusb1 libs present.
> >
> > ___
> > Nut-upsuser mailing list
> > Nut-upsuser@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Eco Eclipse 1600 connects via USB put does not put out any data:

2024-07-12 Thread Stefan Schumacher via Nut-upsuser

Hi
I have installed the following libraries in Debian 12.

ii  libusb-0.1-4:amd64  2:0.1.12-32
  amd64userspace USB programming library
ii  libusb-1.0-0:amd64  2:1.0.26-1
  amd64userspace USB programming library
ii  libusb-1.0-0-dev:amd64  2:1.0.26-1
  amd64userspace USB programming library development files
ii  libusb-1.0-doc  2:1.0.26-1
  all  documentation for userspace USB programming

But when I try configure with :
./configure --with-libsystemd --with-user=nut --with-group=nut --with-usb

I only get the following output. Do I need another version of libusb?
Its version 1.0 and the dev files are there. Normally it should work,
shouldn't it?

configure: can not check libusb settings via pkg-config
checking for libusb-config... no
checking for libusb preferred version... none
configure: WARNING: Defaulting libusb configuration
checking for libusb cflags...
checking for libusb ldflags... -lusb
checking for usb.h... no
checking for usb_init... no
configure: error: USB drivers requested, but libusb not found.


Yours
Stefan

Am Sa., 6. Juli 2024 um 19:57 Uhr schrieb Greg Troxel via Nut-upsuser
:
>
> Stefan Schumacher via Nut-upsuser 
> writes:
>
> > Thanks for the info. Nut runs on bare metal, there is no
> > virtualization layer. I will have a look at the github post after
> > writing this post. I have compiled and installed nut 2.8.2 as
> > suggested. But now I am confused: Where is the usb-hid driver, which I
> > used in Nut 2.8.0? Does one need to pass a special flag to configure
> > to build it?
>
> My memory is that nut builds things if the prereqs are present.
>
> so
>
> ./configure --help
>
> and when you run configure, save stdout/stderr and read it.  especially
> around building usb, and having the libusb1 libs present.
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[jira] [Commented] (CASSANDRA-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865570#comment-17865570
 ] 

Stefan Miklosovic commented on CASSANDRA-19765:
---

Plus to that, if there is some non-super-user role which HAS TO read all roles, 
you can do this:

{code}
cassandra@cqlsh> GRANT DESCRIBE ON ALL ROLES TO iamnosuper;

iamnosuper@cqlsh> list roles;

 role| super | login | options | datacenters
-+---+---+-+-
   cassandra |  True |  True |{} | ALL
  iamnosuper | False |  True |{} | ALL
 iamnosuper2 | False |  True |{} | ALL
  stefan | False | False |{} | ALL

{code}

without granting that, iamnosuper sees just itself.

> Remove accessibility to system_auth.roles salted_hash for non-superusers
> 
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access 
> contents of the salted_hash column. This column contains a bcrypt hash, which 
> shouldn't be visible. This isn't a significant security risk at the current 
> time, but is prone to [retrospective 
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We 
> should protect this column so passwords cannot be cracked in the future.
>  
>  
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND 
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
>  role         | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
>     cassandra |      True |         True |      null | 
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
>  nonsuperuser |      True |        False |      null | 
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>  
> Patches available:
> 3.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865565#comment-17865565
 ] 

Stefan Miklosovic edited comment on CASSANDRA-19765 at 7/12/24 7:01 PM:


I don't know ... the fact that this is by default disabled unless the flag is 
turned on means that operator would need to manually intervene and restart the 
nodes etc. So while they are at it, why do not they just run "REVOKE SELECT ON 
system_auth.roles FROM somerole" in a repeated manner over all non-super-user 
roles and be done with it? This would happen together with a patch which would 
skip granting this on system_auth.roles or other tables in the future if we 
choose so. The effort seems to be same to me.

I get that if we do that, we just prevented non-super-users from reading 
system_auth.roles as a whole, not only salted hash column, but is not this 
quite improbable to happen? What would you need a non-super-user role to read 
system_auth.roles at anyway? Is not that quite a contrived case?

You mentioned that various tool happen to access to various tables, local, 
peers, peers_v2 etc. What non-super-user role just HAS TO read 
system_auth.roles?


was (Author: smiklosovic):
I don't know ... the fact that this is by default disabled unless the flag is 
turned on means that operator would need to manually intervene and restart the 
nodes etc. So while they are at it, why do not they just run "REVOKE SELECT ON 
system_auth.roles FROM somerole" in a repeated manner over all non-super-user 
roles and be done with it? This would happen together with a patch which would 
skip granting this on system_auth.roles or other tables in the future if we 
choose so. The effort seems to be same to me.

> Remove accessibility to system_auth.roles salted_hash for non-superusers
> 
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access 
> contents of the salted_hash column. This column contains a bcrypt hash, which 
> shouldn't be visible. This isn't a significant security risk at the current 
> time, but is prone to [retrospective 
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We 
> should protect this column so passwords cannot be cracked in the future.
>  
>  
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND 
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
>  role         | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
>     cassandra |      True |         True |      null | 
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
>  nonsuperuser |      True |        False |      null | 
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>  
> Patches available:
> 3.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [grpc-io] Re: GRPC C++: Pre-fork worker model

2024-07-12 Thread Stefan Pantos

Thanks Richard. I think I saw this but for some reason I didn’t realise how it was work.Sent from my iPhoneOn 12 Jul 2024, at 18:53, 'Richard Belleville' via grpc.io wrote:Instead of using a parent process / child process model, you could consider cutting out the parent process entirely and using SO_REUSEPORT to handle multiplexing the single address / port combo to multiple worker processes. There's an example in Python here that illustrates this. This should extrapolate pretty straightforwardly to C++.On Friday, July 12, 2024 at 10:12:22 AM UTC-7 Eugene Ostroukhov wrote:gRPC is not designed for this scenario. gRPC closes all file descriptors before forking so the connections would not be available in the client. This is explicit expectation and is covered with this test case - https://github.com/grpc/grpc/blob/master/test/cpp/end2end/client_fork_test.ccOn Monday, December 4, 2023 at 8:02:19 AM UTC-8 stefan pantos wrote:Hi,Is it possible to create a GRPC server in C++ using a pre-fork worker model and can someone point me to an example. I see there are some C prefork related functions but I cannot find an example of using this and cannot quite see how it would work either. I did try myself using AddInsecureChannelFromFd but I didn't have much success not sure if it is me simply making a coding mistake or complete miss understanding of the use case.Incase it isn't clear what I want to do I'll outline the idea in more detail.A parent process creates, binds and listens on the incoming port.Then the child processes are forked, they then do an accept on the now shared file descriptor. Only one of the children will accept a connection and will end up handing that connection but any other connections coming will be handled by one of the other child processes.This is a method outlined in UNIX Network Programming, and I think is a method used in Apache Httpd. The reason I want to use this method is that I have a code base which is not thread safe and it would take a long time and a lot of trial and error to make it thread safe and perform well enough. We have used this method for other protocols with good effect but none of them are as good as GRPC in my opinion.Thanks for any help you can give me in advance.Stefan Pantos

--
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/oSwXlQLQLRM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/86cd9f65-8791-492c-802d-0493705d82c2n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/BB4B9981-6841-4C74-A367-CB9138892CF8%40gmail.com.

[jira] [Commented] (CASSANDRA-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865565#comment-17865565
 ] 

Stefan Miklosovic commented on CASSANDRA-19765:
---

I don't know ... the fact that this is by default disabled unless the flag is 
turned on means that operator would need to manually intervene and restart the 
nodes etc. So while they are at it, why do not they just run "REVOKE SELECT ON 
system_auth.roles FROM somerole" in a repeated manner over all non-super-user 
roles and be done with it? This would happen together with a patch which would 
skip granting this on system_auth.roles or other tables in the future if we 
choose so. The effort seems to be same to me.

> Remove accessibility to system_auth.roles salted_hash for non-superusers
> 
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access 
> contents of the salted_hash column. This column contains a bcrypt hash, which 
> shouldn't be visible. This isn't a significant security risk at the current 
> time, but is prone to [retrospective 
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We 
> should protect this column so passwords cannot be cracked in the future.
>  
>  
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND 
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
>  role         | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
>     cassandra |      True |         True |      null | 
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
>  nonsuperuser |      True |        False |      null | 
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>  
> Patches available:
> 3.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [Interest] problem with type registration during QML module compilation

2024-07-12 Thread Stefan Seefeld

Hello,

any idea why I'm getting the below error ? What tool is used to generate
the *_qmltyperegistrations.cpp file, and how does it figure out to add the
line `#include ` instead of `#include ` ?

On Fri, Jul 5, 2024 at 10:15 AM Stefan Seefeld  wrote:

> Hello,
>
> following up on an earlier conversation...
>
> I'm trying to convert a legacy QML module to use the "new"
> `qt_add_qml_module` function. This process includes the generation of a
> ..._qmltyperegistrations.cpp file that contains an invalid reference to a
> header file 
>
> My library layout looks like this:
>
> libs/foo/
> ├── CMakeLists.txt
> ├── view
> │   ├── A.h
> │   ...
> ├── qml
> ...
>
> and the makefile above compiles a shared library libfoo.so from the
> contents. I now want to use `qt_add_qml_module()` to automate the
> generation of the associated QML module (including all the QML resources,
> as well as exposing the QML types defined in C++, such as the one in
> `view/A.h`. However, the generated code expects to be able to include
> "A.h", while it should actually be including "view/A.h". Is there a
> property I should be passing to `qt_add_qml_module()` to make that happen,
> or is there anything else I'm missing ?
>
> For context: The type `A` is actually a singleton (a QQmlPropertyMap)
> which is accessed directly from C++ code, so its C++ API needs to be
> accessible as a regular class in the library, in addition to being
> registered to the QML runtime.
>
> Thanks for any help,
>
> --
>
>   ...ich hab' noch einen Koffer in Berlin...
>
>

-- 

  ...ich hab' noch einen Koffer in Berlin...
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

adaptTo() 2024: Agenda online

2024-07-12 Thread Stefan Seifert

Dear adaptTo() Community,

Exciting news! The agenda for adaptTo() 2024, Europe's leading AEM Developer 
Conference, has been announced!
https://adapt.to/2024/schedule

Tickets are still available:
https://adapt.to/tickets

The conference takes place October 21st to 23rd, 2024 in Berlin, Germany.

Your adaptTo() Conference Team

adaptTo() 2024: Agenda online

2024-07-12 Thread Stefan Seifert

Dear adaptTo() Community,

Exciting news! The agenda for adaptTo() 2024, Europe's leading AEM Developer 
Conference, has been announced!
https://adapt.to/2024/schedule

Tickets are still available:
https://adapt.to/tickets

The conference takes place October 21st to 23rd, 2024 in Berlin, Germany.

Your adaptTo() Conference Team

[gcc r15-2002] s390: Fully exploit vgm, vgbm, vrepi

2024-07-12 Thread Stefan Schulze Frielinghaus via Gcc-cvs

https://gcc.gnu.org/g:61715e9340ab8941d40d62158fe437e9dbe3e068

commit r15-2002-g61715e9340ab8941d40d62158fe437e9dbe3e068
Author: Stefan Schulze Frielinghaus 
Date:   Fri Jul 12 13:42:08 2024 +0200

s390: Fully exploit vgm, vgbm, vrepi

Currently instructions vgm and vrepi are utilized only for constant
vectors where the element mode equals the element mode of the
corresponding instruction.  This patch lifts this restriction by making
use of those instructions for constant vectors even if element modes
do not coincide.  For example, the constant vector

  (v2di){0x7ffe7ffe, 0x7ffe7ffe}

can be loaded via vgmf %v0,1,30.  Similar, the constant vector

  (v4si){0x, 0x, 0x, 0x}

can be loaded via vrepiq %v0,-86.

Analog, if the element mode of a constant vector is smaller than the
element mode of a corresponding instruction, we still may make use of
those instructions.  For example, the constant vector

  (v4si){0x7fff, 0xfffe, 0x7fff, 0xfffe}

can be loaded via vgmg %v0,17,46.  Similar, the constant vector

  (v4si){-1, -16643, -1, -16643}

can be loaded via vrepig %v0,-16643.

Additionally this patch enables vgm, vgbm, vrepi for partial vectors,
i.e., vectors of size less than 16 bytes.  Basically this is done by
treating a vector as a full vector resulting in replicating constants
into the ignored bits whereas vgbm sets those to zero.

Furthermore, there is no restriction to integer vectors anymore, i.e.,
supporting scalars of mode up to and including TI and TF and also
floating-point vectors.

Here are some numbers how often instructions are emitted for SPEC 2017:

w/o patch w/ patch
vgbm  140  365
vgm 1750824452
vrepi1360 2775

I expect most (maybe even all) to save us a load from the literal pool.

gcc/ChangeLog:

* config/s390/2964.md: Remove extended mnemonics for vgm.
* config/s390/3906.md: Remove extended mnemonics for vgm.
* config/s390/3931.md: Remove extended mnemonics for vgm.
* config/s390/8561.md: Remove extended mnemonics for vgm.
* config/s390/constraints.md (jKK): Remove constraint.
(jzz): Add constraint.
* config/s390/s390-protos.h (s390_contiguous_bitmask_vector_p):
Add prototype.
(s390_constant_via_vgm_p): Add prototype.
(s390_constant_via_vrepi_p): Add prototype.
* config/s390/s390.cc (s390_contiguous_bitmask_vector_p): New
function.
(s390_constant_via_vgm_vrepi_helper): New function.
(s390_constant_via_vgm_p): New function.
(s390_constant_via_vgbm_p): For the sake of symmetry rename
s390_bytemask_vector_p into s390_constant_via_vgbm_p.
(s390_bytemask_vector_p): Deal with non-integer and partial
vectors.
(s390_constant_via_vrepi_p): New function.
(s390_legitimate_constant_p): Allow partial vectors.
(legitimate_reload_constant_p): Fix indentation.
(legitimate_reload_vector_constant_p): Restrict to constraints
j00, jm1, jxx, jyy, jzz only, i.e., allow partial vectors.
(s390_expand_vec_init): Also make use of vrepi if possible.
(print_operand): Add q,p,r for vgm,vrepi,vgbm, respectively.
Remove e,s,t for constant vectors.
* config/s390/s390.md (movti): Add variants utilizing
vgbm,vgm,vrepi.
* config/s390/vector.md (mov): Adapt variants
for vgbm,vgm,vrepi for the new scheme.
(mov): Adapt variants for vgbm,vgm for the new
scheme and add vrepi variant for modes V_8,V_16,V_32,V_64.

gcc/testsuite/ChangeLog:

* gcc.target/s390/vector/vec-copysign.c: Change to non-extended
mnemonic.
* gcc.target/s390/vector/vec-genmask-1.c: Change to non-extended
mnemonic.
* gcc.target/s390/vector/vec-init-1.c: Change to non-extended
mnemonic.
* gcc.target/s390/vector/vec-vrepi-1.c: Change to non-extended
mnemonic.
* gcc.target/s390/zvector/autovec-double-quiet-uneq.c: Change to
non-extended mnemonic.
* gcc.target/s390/zvector/autovec-float-quiet-uneq.c: Change to
non-extended mnemonic.
* gcc.target/s390/zvector/vec-genmask-1.c: Change to
non-extended mnemonic.
* gcc.target/s390/zvector/vec-splat-1.c: Change to non-extended
mnemonic.
* gcc.target/s390/zvector/vec-splat-2.c: Change to non-extended
mnemonic.
* gcc.target/s390/vector/vgbm-double-1.c: New test.
* gcc.target/s390/vector/vgbm

[gcc r15-2001] s390: Fix output template for movv1qi

2024-07-12 Thread Stefan Schulze Frielinghaus via Gcc-cvs

https://gcc.gnu.org/g:e6680d3f392f7f7cc2a1515276213e21e9eeab1c

commit r15-2001-ge6680d3f392f7f7cc2a1515276213e21e9eeab1c
Author: Stefan Schulze Frielinghaus 
Date:   Fri Jul 12 13:40:19 2024 +0200

s390: Fix output template for movv1qi

Although for instructions MVI and MVIY it does not make a difference
whether the immediate is interpreted as signed or unsigned, GAS expects
unsigned immediates for instruction format SI_URD.

gcc/ChangeLog:

* config/s390/vector.md (mov): Fix output template for
movv1qi.

Diff:
---
 gcc/config/s390/vector.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
index 40de0c75a7cf..26fd505f2cd9 100644
--- a/gcc/config/s390/vector.md
+++ b/gcc/config/s390/vector.md
@@ -368,8 +368,8 @@
lr\t%0,%1
mvi\t%0,0
mviy\t%0,0
-   mvi\t%0,-1
-   mviy\t%0,-1
+   mvi\t%0,255
+   mviy\t%0,255
lhi\t%0,0
lhi\t%0,-1
llc\t%0,%1

[gcc r15-1999] s390: Align cjump_64 and icjump_64

2024-07-12 Thread Stefan Schulze Frielinghaus via Gcc-cvs

https://gcc.gnu.org/g:56de68aba6cb9cf3022d9e303eec6c6cdb49ad4d

commit r15-1999-g56de68aba6cb9cf3022d9e303eec6c6cdb49ad4d
Author: Stefan Schulze Frielinghaus 
Date:   Fri Jul 12 13:27:08 2024 +0200

s390: Align *cjump_64 and *icjump_64

During machine reorg we optimize backward jumps and transform insns as
e.g.

(jump_insn 118 117 119 (set (pc)
(if_then_else (ne (reg:CCRAW 33 %cc)
(const_int 8 [0x8]))
(label_ref 134)
(pc))) "dec_math_1.f90":204:8 discrim 1 2161 {*cjump_64}
 (expr_list:REG_DEAD (reg:CCRAW 33 %cc)
(int_list:REG_BR_PROB 719407028 (nil)))
 -> 134)

into

(jump_insn 118 117 432 (set (pc)
(if_then_else (ne (reg:CCRAW 33 %cc)
(const_int 8 [0x8]))
(pc)
(label_ref 433))) "dec_math_1.f90":204:8 discrim 1 -1
 (expr_list:REG_DEAD (reg:CCRAW 33 %cc)
(int_list:REG_BR_PROB 719407028 (nil)))
 -> 433)

The latter is not recognized anymore since *icjump_64 only matches
CC_REGNUM against zero.  Fixed by aligning *cjump_64 and *icjump_64.

gcc/ChangeLog:

* config/s390/s390.md (*icjump_64): Allow raw CC comparisons,
i.e., any constant integer between 0 and 15 for CC comparisons.

Diff:
---
 gcc/config/s390/s390.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 1311a5f01cf3..2555006bb4b9 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -9530,7 +9530,8 @@
 (define_insn "*icjump_64"
   [(set (pc)
 (if_then_else
-  (match_operator 1 "s390_comparison" [(reg CC_REGNUM) (const_int 0)])
+  (match_operator 1 "s390_comparison" [(reg CC_REGNUM)
+  (match_operand 2 
"const_int_operand" "")])
   (pc)
   (label_ref (match_operand 0 "" ""]
   ""

[SCM] Samba Shared Repository - branch master updated

2024-07-12 Thread Stefan Metzmacher

The branch, master has been updated
   via  e450ff685b5 pidl: Wireshark: Another C99 type conversion
   via  9870457e962 pidl: Wireshark: Don't assign hash undef, assign it an 
empty array
   via  5b12d3d2e7d pidl: Wireshark: Remove init of proto variables
   via  00f57728742 pidl: Wireshark: Convert the pidl dissector generation 
code to C99 types
   via  e60c5b881d9 pidl: Wireshark: Update test for removal of ett 
initialization
   via  2f5a388dd10 pidl: Wireshark: Const-ify dcerpc_sub_dissector 
structures.
   via  5a5e68c2747 pidl: Wireshark: Don't initialise static hf and ett 
variables.
   via  f2ed371e1cc pidl: Wireshark: Remove init of proto variables
   via  c3ca2a6575b pidl: Update Wireshark generated DRSUAPI code
  from  3a21b7d9a4e .gitlab-ci-main.yml: Add safe.directory '*'

https://git.samba.org/?p=samba.git;a=shortlog;h=master


- Log -
commit e450ff685b57849470aecdab5397a1a8ea5d19d2
Author: John Thacker 
Date:   Wed Jul 3 08:03:41 2024 -0400

pidl: Wireshark: Another C99 type conversion

Pick up change from Wireshark:

commit bdb719f846f9d8f7800b9f50dadfde5e7f7a89e1
Author: John Thacker 
Date:   Sun Jun 23 08:15:45 2024 -0400

pidl: Another C99 type conversion

Change an automated sizeof() call in the pidl dissector generation 
from
prefixing a "g" to getting the actual C type.

Ping #19116

Signed-off-by: John Thacker 
Reviewed-by: Jo Sutton 
Reviewed-by: Stefan Metzmacher 

Autobuild-User(master): Stefan Metzmacher 
Autobuild-Date(master): Fri Jul 12 11:08:03 UTC 2024 on atb-devel-224

commit 9870457e962b2ce2da590777aa4f58269361b95b
Author: John Thacker 
Date:   Wed Jul 3 08:00:59 2024 -0400

pidl: Wireshark: Don't assign hash undef, assign it an empty array

Pick up change from Wireshark:

commit ade6577f109e2bf741909226254b758e79a816f1
Author: John Thacker 
Date:   Fri Jun 21 20:27:51 2024 -0400

pidl: Don't assign hash undef, assign it an empty array

Perl works, but complains if warnings are on, if a hash is
initialized to undef instead of to empty. Upstream Samba turned on
warnings in the next commit to catch things like this.

Signed-off-by: John Thacker 
Reviewed-by: Jo Sutton 
Reviewed-by: Stefan Metzmacher 

commit 5b12d3d2e7d82bc07c1c1c96229ed0cd71a6a967
Author: John Thacker 
Date:   Wed Jul 3 07:58:04 2024 -0400

pidl: Wireshark: Remove init of proto variables

Pick up change from Wireshark:

commit 10b046cbdd110dbae8f4cab048e5954bf6955402
Author: John Thacker 
Date:   Sat Jun 22 20:31:40 2024 -0400

pidl: Remove init of proto variables

Remove initialization of proto variables from pidl generated 
dissectors
and regenerate.
Follow up to 2a9bc63325c99653c5da873c273430add3b5e9dd

Signed-off-by: John Thacker 
Reviewed-by: Jo Sutton 
Reviewed-by: Stefan Metzmacher 

commit 00f5772874265d0cd8535cd60a76e6117ce715b5
Author: John Thacker 
Date:   Wed Jul 3 07:56:42 2024 -0400

pidl: Wireshark: Convert the pidl dissector generation code to C99 types

Pick up change from Wireshark:

commit 4df8d2884ddfe72a03d0b322c10ae515a8366ea4
Author: John Thacker 
Date:   Sat Jun 22 11:21:47 2024 -0400

pidl: Convert the pidl dissector generation code to C99 types

Switch the Wireshark.pm pidl dissector generation code to using C99
types, and regenerated the dcerpc pidl dissectors.

Ping #19116

Signed-off-by: John Thacker 
Reviewed-by: Jo Sutton 
Reviewed-by: Stefan Metzmacher 

commit e60c5b881d95d7b6073abc87d42ecba52778f192
Author: John Thacker 
Date:   Wed Jul 3 07:54:40 2024 -0400

pidl: Wireshark: Update test for removal of ett initialization

Pick up change from Wireshark:

commit 6e4c81b324e9b1752ce6bc253a09355512b5b387
Author: John Thacker 
Date:   Sat Jun 22 11:10:48 2024 -0400

pidl: Update test for removal of ett initialization

Also remove trailing whitespace

Signed-off-by: John Thacker 
Reviewed-by: Jo Sutton 
Reviewed-by: Stefan Metzmacher 

commit 2f5a388dd105f43d69b730f05be1b1b109c87212
Author: John Thacker 
Date:   Wed Jul 3 07:52:42 2024 -0400

pidl: Wireshark: Const-ify dcerpc_sub_dissector structures.

Pick up change from Wireshark:

commit 8a2a42241fd148ce735e776a6a1e6b49b64d215e
Author: Darius Davis 
Date:   Sun May 19 17:39:38 2024 +1000

Const-ify dcerpc_sub_dissector structures.

This moves about 56 kBytes of data from a read-write data sectio

[jira] [Comment Edited] (CASSANDRA-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865407#comment-17865407
 ] 

Stefan Miklosovic edited comment on CASSANDRA-19765 at 7/12/24 10:26 AM:
-

Would not it be better if this was treated not on SELECT level but directly 
when we are executing "GRANT SELECT ON system_auth.roles TO nonsuperuser;"? Why 
not to reject this upon granting rather than checking this on every select? 
Might it be extension of Sam's patch somehow or is that already baked in?

Does it relate to this: "but permission-tightening across the entire resource 
hierarchy is complicated and blocking access to just this column is fairly 
simple."?

If so, what is complicated about that? Can you elaborate? By this approach it 
seems like we are plumbing it _after it happened_, we are not preventing it 
from happening.


was (Author: smiklosovic):
Would not it be better if this was treated not on SELECT level but directly 
when we are executing "GRANT SELECT ON system_auth.roles TO nonsuperuser;"? Why 
not to reject this upon granting rather than checking this on every select?

Does it relate to this: "but permission-tightening across the entire resource 
hierarchy is complicated and blocking access to just this column is fairly 
simple."?

If so, what is complicated about that? Can you elaborate? By this approach it 
seems like we are plumbing it _after it happened_, we are not preventing it 
from happening.

> Remove accessibility to system_auth.roles salted_hash for non-superusers
> 
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access 
> contents of the salted_hash column. This column contains a bcrypt hash, which 
> shouldn't be visible. This isn't a significant security risk at the current 
> time, but is prone to [retrospective 
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We 
> should protect this column so passwords cannot be cracked in the future.
>  
>  
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND 
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
>  role         | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
>     cassandra |      True |         True |      null | 
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
>  nonsuperuser |      True |        False |      null | 
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>  
> Patches available:
> 3.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865407#comment-17865407
 ] 

Stefan Miklosovic edited comment on CASSANDRA-19765 at 7/12/24 10:25 AM:
-

Would not it be better if this was treated not on SELECT level but directly 
when we are executing "GRANT SELECT ON system_auth.roles TO nonsuperuser;"? Why 
not to reject this upon granting rather than checking this on every select?

Does it relate to this: "but permission-tightening across the entire resource 
hierarchy is complicated and blocking access to just this column is fairly 
simple."?

If so, what is complicated about that? Can you elaborate? By this approach it 
seems like we are plumbing it _after it happened_, we are not preventing it 
from happening.


was (Author: smiklosovic):
Would not it be better if this was treated not on SELECT level but directly 
when we are executing "GRANT SELECT ON system_auth.roles TO nonsuperuser;"? Why 
not to reject this upon granting rather than checking this on every select?

Does it related to this: "but permission-tightening across the entire resource 
hierarchy is complicated and blocking access to just this column is fairly 
simple."?

If so, what is complicated about that? Can you elaborate? By this approach it 
seems like we are plumbing it _after it happened_, we are not preventing it 
from happening.

> Remove accessibility to system_auth.roles salted_hash for non-superusers
> 
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access 
> contents of the salted_hash column. This column contains a bcrypt hash, which 
> shouldn't be visible. This isn't a significant security risk at the current 
> time, but is prone to [retrospective 
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We 
> should protect this column so passwords cannot be cracked in the future.
>  
>  
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND 
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
>  role         | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
>     cassandra |      True |         True |      null | 
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
>  nonsuperuser |      True |        False |      null | 
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>  
> Patches available:
> 3.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Comment Edited] (CASSANDRA-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865407#comment-17865407
 ] 

Stefan Miklosovic edited comment on CASSANDRA-19765 at 7/12/24 10:25 AM:
-

Would not it be better if this was treated not on SELECT level but directly 
when we are executing "GRANT SELECT ON system_auth.roles TO nonsuperuser;"? Why 
not to reject this upon granting rather than checking this on every select?

Does it related to this: "but permission-tightening across the entire resource 
hierarchy is complicated and blocking access to just this column is fairly 
simple."?

If so, what is complicated about that? Can you elaborate? By this approach it 
seems like we are plumbing it _after it happened_, we are not preventing it 
from happening.


was (Author: smiklosovic):
Would not it be better if this was treated not on SELECT level but directly 
when we are executing "GRANT SELECT ON system_auth.roles TO nonsuperuser;"? Why 
not to reject this upon granting rather than checking this on every select?

> Remove accessibility to system_auth.roles salted_hash for non-superusers
> 
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access 
> contents of the salted_hash column. This column contains a bcrypt hash, which 
> shouldn't be visible. This isn't a significant security risk at the current 
> time, but is prone to [retrospective 
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We 
> should protect this column so passwords cannot be cracked in the future.
>  
>  
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND 
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
>  role         | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
>     cassandra |      True |         True |      null | 
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
>  nonsuperuser |      True |        False |      null | 
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>  
> Patches available:
> 3.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865407#comment-17865407
 ] 

Stefan Miklosovic commented on CASSANDRA-19765:
---

Would not it be better if this was treated not on SELECT level but directly 
when we are executing "GRANT SELECT ON system_auth.roles TO nonsuperuser;"? Why 
not to reject this upon granting rather than checking this on every select?

> Remove accessibility to system_auth.roles salted_hash for non-superusers
> 
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access 
> contents of the salted_hash column. This column contains a bcrypt hash, which 
> shouldn't be visible. This isn't a significant security risk at the current 
> time, but is prone to [retrospective 
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We 
> should protect this column so passwords cannot be cracked in the future.
>  
>  
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND 
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
>  role         | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
>     cassandra |      True |         True |      null | 
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
>  nonsuperuser |      True |        False |      null | 
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>  
> Patches available:
> 3.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[ceph-users] Re: cephadm for Ubuntu 24.04

2024-07-12 Thread Stefan Kooman


On 12-07-2024 09:33, tpDev Tester wrote:

Hi,

Am 11.07.2024 um 14:20 schrieb John Mulligan:

...


as far as I know, we still have an issue

https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/2063456

with ceph on 24.04. I tried the offered fix, but was still unable to 
establish a running cluster (may be my fault, I'm still a newbie to this).


You can download this package and install it manually:

(first remove the old package: apt purge cephadm)

wget 
http://launchpadlibrarian.net/735185237/cephadm_19.2.0~git20240301.4c76c50-0ubuntu6.1_amd64.deb


dpkg -i cephadm_19.2.0~git20240301.4c76c50-0ubuntu6.1_amd64.deb

This version worked for a Reef cluster (18.2.1) on 24.04. But you can 
also download a 18.2.1 version with the apparmor fix backported from here:


https://kooman.org/cephadm

sha256sum cephadm
0067d9951cdf31b26788bfd4775913992672c8cf652215650997d4da2dc8d5a3  cephadm

Then what? I copied the "cephadm" file to "/usr/sbin/cephadm" and 
"/var/lib/ceph/{fsid-of-your-cluster/cephadm.verylongstringhere"


Or let me know what version you need, building cephadm is really trivial.

Note: just to be sure, you do _NOT_ want to use Ceph from Ubuntu 24.04 
repositories. The 19.2.x release is not out yet (still RC) and this is a 
Ubuntu released version (why they ship this in a Ubuntu LTS version 
instead of a stable Ceph release is beyond me, but they might have their 
reasons ... @Canonical folks please chime in here).


Gr. Stefan
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

[jira] [Commented] (CASSANDRA-19765) Remove accessibility to system_auth.roles salted_hash for non-superusers



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865351#comment-17865351
 ] 

Stefan Miklosovic commented on CASSANDRA-19765:
---

I wonder what would be the motivation for a superuser to grant select on 
system_auth.roles to a nonsuperuser?

> Remove accessibility to system_auth.roles salted_hash for non-superusers
> 
>
> Key: CASSANDRA-19765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19765
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Legacy/Core
>Reporter: Abe Ratnofsky
>Assignee: Abe Ratnofsky
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x
>
>
> Cassandra permits all users with SELECT on system_auth.roles to access 
> contents of the salted_hash column. This column contains a bcrypt hash, which 
> shouldn't be visible. This isn't a significant security risk at the current 
> time, but is prone to [retrospective 
> decryption|https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later]. We 
> should protect this column so passwords cannot be cracked in the future.
>  
>  
> {code:java}
> $ ./bin/cqlsh -u cassandra -p cassandra
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> cassandra@cqlsh> CREATE ROLE nonsuperuser WITH LOGIN=true AND 
> PASSWORD='nonsuperuser';
> cassandra@cqlsh> GRANT SELECT ON system_auth.roles TO nonsuperuser;
> cassandra@cqlsh> exit;
> $ ./bin/cqlsh -u nonsuperuser -p nonsuperuser
> [cqlsh 6.3.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
> nonsuperuser@cqlsh> SELECT * FROM system_auth.roles;
>  role         | can_login | is_superuser | member_of | salted_hash
> --+---+--+---+--
>     cassandra |      True |         True |      null | 
> $2a$10$WMg9UlR7F8Ko7LZxEyg0Ue12BoHR/Dn/0/3YtV4nRYCPcY7/5OmA6
>  nonsuperuser |      True |        False |      null | 
> $2a$10$HmHwVZRk8F904UUNMiUYi.xkVglWyKNgHMo1xJsCCKirwyb9NO/im
> (2 rows)
> {code}
>  
> Patches available:
> 3.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-30
> 3.11: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-311
> 4.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-40
> 4.1: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-41
> 5.0: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-50
> trunk: 
> https://github.com/apache/cassandra/compare/trunk...aratno:cassandra:CASSANDRA-19765-salted_hash-visibility-trunk



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-19766) Optionally disable cqlsh HISTORY command via env variable



[ 
https://issues.apache.org/jira/browse/CASSANDRA-19766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865349#comment-17865349
 ] 

Stefan Miklosovic commented on CASSANDRA-19766:
---

[~maedhroz] doesnt this solve it?

https://github.com/apache/cassandra/commit/e9ca46546875f0e1737ed88a6c5823b9b127c0bb

> Optionally disable cqlsh HISTORY command via env variable
> -
>
> Key: CASSANDRA-19766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19766
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> There may be cases where we’d like to disable the saving and display of the 
> history of {{cqlsh}} commands executed. This should be fairly straightforward 
> to do via an environment variable.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Re: [PATCH] s390: Align cjump_64 and icjump_64

On Thu, Jul 11, 2024 at 07:32:17PM +0200, Stefan Schulze Frielinghaus wrote:
> On Thu, Jul 11, 2024 at 05:14:58PM +0200, Jakub Jelinek wrote:
> > On Thu, Jul 11, 2024 at 05:09:41PM +0200, Stefan Schulze Frielinghaus wrote:
> > > I didn't have the schedule for 11.5 RC in mind which is tomorrow and the
> > > release a week afterwards.  I hope this is still appropriate for 11.5?
> > 
> > From my side, if Andreas or somebody else approves it, it is tested on 11
> > branch and committed by tomorrow, it can be added.
> > But I'd like to know what patches I should wait for tomorrow and approximate
> > ETA (and ideally before end of working day in Europe).  Once rc1 is done, 
> > only
> > severe blockers will be possible.
> 
> The tester is running over night and will finish around 7 AM CEST.  I
> will let you know once it has finished.  If anything goes wrong we can
> skip this patch of course.

The tester was extremely slow this time and still didn't finish.  I
don't wanna rush it risking to introduce late time problems for the
11.5 release.  Since I'm testing for three different architectures and
the first one hasn't finished, let's drop this patch for 11.5.

Sorry for the noise,
Stefan

Re: [PATCH] s390: Align cjump_64 and icjump_64

On Thu, Jul 11, 2024 at 05:14:58PM +0200, Jakub Jelinek wrote:
> On Thu, Jul 11, 2024 at 05:09:41PM +0200, Stefan Schulze Frielinghaus wrote:
> > I didn't have the schedule for 11.5 RC in mind which is tomorrow and the
> > release a week afterwards.  I hope this is still appropriate for 11.5?
> 
> From my side, if Andreas or somebody else approves it, it is tested on 11
> branch and committed by tomorrow, it can be added.
> But I'd like to know what patches I should wait for tomorrow and approximate
> ETA (and ideally before end of working day in Europe).  Once rc1 is done, only
> severe blockers will be possible.

The tester is running over night and will finish around 7 AM CEST.  I
will let you know once it has finished.  If anything goes wrong we can
skip this patch of course.

Cheers,
Stefan

Re: [pve-devel] [PATCH installer 00/14] fix #5536: implement post-(auto-)installation notification mechanism

Did a quick smoke test of this series by creating an ISO with an answer
file baked in and checking the response via `nc -l`. Review is inline.

Consider this:

Tested-By: Stefan Hanreich 
Reviewed-By: Stefan Hanreich 


On 7/10/24 15:27, Christoph Heiss wrote:
> This implements a mechanism for post-installation "notifications" via a
> POST request [0] when using the auto-installer.
> 
> It's implemented as a separate, small utility to facilitate separation
> of concerns and make the information gathering easier by having it
> isolated in one place.
> 
> Patches #1 through #10 are simply clean-ups, refactors, etc. that were
> done along the way, which do not impact functionality in any way.
> 
> Most interesting here will be patch #12, which adds the actual
> implementation of the post-hook. (Bind-)mounting the installed host
> system is done using the existing `proxmox-chroot` utility, and the HTTP
> POST functionality can fortunately be re-used 1:1 from
> `proxmox-fetch-answer`.
> 
> I've also included an example of how the JSON body (pretty-printed for
> readability) of such a post-installation request would look like below,
> for reference.
> 
> Tested this with both PVE and PBS ISOs, PMG did not (yet) have a
> release with an auto-installation capable ISO. The only product-specific
> code is the version detection in `proxmox-post-hook`, which - since it
> works the same for PVE and PMG - be no obstacle.
> 
> [0] https://bugzilla.proxmox.com/show_bug.cgi?id=5536
> 
> {
>   "debian-version": "12.5",
>   "product-version": "pve-manager/8.2.2/9355359cd7afbae4",
>   "kernel-version": "proxmox-kernel-6.8.4-2-pve-signed",
>   "boot-type": "bios",
>   "filesystem": "zfs (RAID1)",
>   "fqdn": "host.domain",
>   "machine-id": "f4bf9711783248b7aaffe3ccbca3e3dc",
>   "bootdisk": [
> {
>   "size": 8589934592,
>   "udev-properties": {
> "DEVNAME": "/dev/vda", [..]
>   }
> },
> {
>   "size": 8589934592,
>   "udev-properties": {
> "DEVNAME": "/dev/vdb", [..]
>   }
> }
>   ],
>   "management-nic": {
> "mac": "de:ad:f0:0d:12:34",
> "address": "10.0.0.10/24",
> "udev-properties": {
>   "INTERFACE": "enp6s18", [..]
> }
>   },
>   "ssh-public-host-keys": {
> "ecdsa": "ecdsa-sha2-nistp256 [..] root@host",
> "ed25519": "ssh-ed25519 [..] root@host",
> "rsa": "ssh-rsa [..] root@host",
>   }
> }
> 
> Christoph Heiss (14):  chroot: print full anyhow message
>   tree-wide: fix some typos
>   tree-wide: collect hardcoded installer runtime directory strings into
> constant
>   common: simplify filesystem type serializing & Display trait impl
>   common: setup: serialize `target_hd` as string explicitly
>   common: split out installer setup files loading functionality
>   debian: strip unused library dependencies
>   fetch-answer: move http-related code to gated module in
> installer-common
>   tree-wide: convert some more crates to use workspace dependencies
>   auto-installer: tests: replace left/right with got/expected in output
>   auto-installer: answer: add `posthook` section
>   fix #5536: add post-hook utility for sending notifications after
> auto-install
>   fix #5536: post-hook: add some unit tests
>   unconfigured.sh: run proxmox-post-hook after successful auto-install
> 
>  Cargo.toml|  11 +
>  Makefile  |   8 +-
>  debian/control|   1 +
>  debian/install|   1 +
>  debian/rules  |   9 +
>  proxmox-auto-install-assistant/Cargo.toml |  14 +-
>  proxmox-auto-installer/Cargo.toml |  15 +-
>  proxmox-auto-installer/src/answer.rs  |  27 +-
>  .../src/bin/proxmox-auto-installer.rs |  15 +-
>  proxmox-auto-installer/src/sysinfo.rs |  10 +-
>  proxmox-auto-installer/src/utils.rs   |  15 +-
>  proxmox-auto-installer/tests/parse-answer.rs  |  42 +-
>  proxmox-chroot/Cargo.toml |   8 +-
>  proxmox-chroot/src/main.rs|  19 +-
>  proxmox-fetch-answer/Cargo.toml   |  17 +-
>  .../src/fetch_plugins/http.rs | 100 +---
>  .../src/fetch_plugins/partition.rs|  14 +-
>

Re: [pve-devel] [PATCH installer 12/14] fix #5536: add post-hook utility for sending notifications after auto-install




On 7/10/24 15:27, Christoph Heiss wrote:
> +impl Answer {
> +pub fn from_reader(reader: impl BufRead) -> Result {
> +let mut buffer = String::new();
> +let lines = reader.lines();
> +for line in lines {
> +buffer.push_str(());
> +buffer.push('\n');
> +}
> +
> +toml::from_str().map_err(|err| format_err!("Failed parsing 
> answer file: {err}"))
> +}
> +}

maybe better impl TryFrom for Answer ? Or at least call
the method try_from_reader if it returns a result?

>  #[derive(Clone, Deserialize, Debug)]
>  #[serde(deny_unknown_fields)]
>  pub struct Global {
> diff --git a/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs 
> b/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
> index bf6f8fb..aab0f1f 100644
> --- a/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
> +++ b/proxmox-auto-installer/src/bin/proxmox-auto-installer.rs
> @@ -42,16 +42,7 @@ fn auto_installer_setup(in_test_mode: bool) -> 
> Result<(Answer, UdevInfo)> {
>  .map_err(|err| format_err!("Failed to retrieve udev info 
> details: {err}"))?
>  };
>  
> -let mut buffer = String::new();
> -let lines = std::io::stdin().lock().lines();
> -for line in lines {
> -buffer.push_str(());
> -buffer.push('\n');
> -}
> -
> -let answer: Answer =
> -toml::from_str().map_err(|err| format_err!("Failed parsing 
> answer file: {err}"))?;
> -
> +let answer = Answer::from_reader(std::io::stdin().lock())?;
>  Ok((answer, udev_info))
>  }
>  
> @@ -91,8 +82,6 @@ fn main() -> ExitCode {
>  }
>  }
>  
> -// TODO: (optionally) do a HTTP post with basic system info, like host 
> SSH public key(s) here
> -
>  ExitCode::SUCCESS
>  }
>  
> diff --git a/proxmox-fetch-answer/src/fetch_plugins/http.rs 
> b/proxmox-fetch-answer/src/fetch_plugins/http.rs
> index a6a8de0..4317430 100644
> --- a/proxmox-fetch-answer/src/fetch_plugins/http.rs
> +++ b/proxmox-fetch-answer/src/fetch_plugins/http.rs
> @@ -68,7 +68,7 @@ impl FetchFromHTTP {
>  let payload = SysInfo::as_json()?;
>  info!("Sending POST request to '{answer_url}'.");
>  let answer =
> -proxmox_installer_common::http::post(answer_url, 
> fingerprint.as_deref(), payload)?;
> +proxmox_installer_common::http::post(_url, 
> fingerprint.as_deref(), payload)?;
>  Ok(answer)
>  }
>  
> diff --git a/proxmox-fetch-answer/src/fetch_plugins/partition.rs 
> b/proxmox-fetch-answer/src/fetch_plugins/partition.rs
> index 4472922..f07389b 100644
> --- a/proxmox-fetch-answer/src/fetch_plugins/partition.rs
> +++ b/proxmox-fetch-answer/src/fetch_plugins/partition.rs
> @@ -31,7 +31,7 @@ impl FetchFromPartition {
>  }
>  
>  fn path_exists_logged(file_name: , search_path: ) -> Option 
> {
> -let path = Path::new(search_path).join(_name);
> +let path = Path::new(search_path).join(file_name);
>  info!("Testing partition search path {path:?}");
>  match path.try_exists() {
>  Ok(true) => Some(path),
> diff --git a/proxmox-installer-common/src/http.rs 
> b/proxmox-installer-common/src/http.rs
> index 4a5d444..b754ed8 100644
> --- a/proxmox-installer-common/src/http.rs
> +++ b/proxmox-installer-common/src/http.rs
> @@ -15,7 +15,7 @@ use ureq::{Agent, AgentBuilder};
>  /// * `url` - URL to call
>  /// * `fingerprint` - SHA256 cert fingerprint if certificate pinning should 
> be used. Optional.
>  /// * `payload` - The payload to send to the server. Expected to be a JSON 
> formatted string.
> -pub fn post(url: String, fingerprint: Option<>, payload: String) -> 
> Result {
> +pub fn post(url: , fingerprint: Option<>, payload: String) -> 
> Result {
>  let answer;
>  
>  if let Some(fingerprint) = fingerprint {
> @@ -27,7 +27,7 @@ pub fn post(url: String, fingerprint: Option<>, 
> payload: String) -> Result  let agent: Agent = 
> AgentBuilder::new().tls_config(Arc::new(tls_config)).build();
>  
>  answer = agent
> -.post()
> +.post(url)
>  .set("Content-Type", "application/json; charset=utf-8")
>  .send_string()?
>  .into_string()?;
> @@ -47,7 +47,7 @@ pub fn post(url: String, fingerprint: Option<>, 
> payload: String) -> Result  .tls_config(Arc::new(tls_config))
>  .build();
>  answer = agent
> -.post()
> +.post(url)
>  .set("Content-Type", "application/json; charset=utf-8")
>  .timeout(std::time::Duration::from_secs(60))
>  .send_string()?
> diff --git a/proxmox-installer-common/src/options.rs 
> b/proxmox-installer-common/src/options.rs
> index 9f6131b..b209587 100644
> --- a/proxmox-installer-common/src/options.rs
> +++ b/proxmox-installer-common/src/options.rs
> @@ -45,6 +45,10 @@ impl FsType {
>  pub fn is_btrfs() -> bool {
>  matches!(self, FsType::Btrfs(_))
>  }
> +
> +pub fn is_lvm() ->

Re: [PATCH] s390: Align cjump_64 and icjump_64

On Thu, Jul 11, 2024 at 04:29:19PM +0200, Stefan Schulze Frielinghaus wrote:
> During machine reorg we optimize backward jumps and transform insns as
> e.g.
> 
> (jump_insn 118 117 119 (set (pc)
> (if_then_else (ne (reg:CCRAW 33 %cc)
> (const_int 8 [0x8]))
> (label_ref 134)
> (pc))) "dec_math_1.f90":204:8 discrim 1 2161 {*cjump_64}
>  (expr_list:REG_DEAD (reg:CCRAW 33 %cc)
> (int_list:REG_BR_PROB 719407028 (nil)))
>  -> 134)
> 
> into
> 
> (jump_insn 118 117 432 (set (pc)
> (if_then_else (ne (reg:CCRAW 33 %cc)
> (const_int 8 [0x8]))
> (pc)
> (label_ref 433))) "dec_math_1.f90":204:8 discrim 1 -1
>  (expr_list:REG_DEAD (reg:CCRAW 33 %cc)
> (int_list:REG_BR_PROB 719407028 (nil)))
>  -> 433)
> 
> The latter is not recognized anymore since *icjump_64 only matches
> CC_REGNUM against zero.  Fixed by aligning *cjump_64 and *icjump_64.
> 
> gcc/ChangeLog:
> 
>   * config/s390/s390.md (*icjump_64): Allow raw CC comparisons,
>   i.e., any constant integer between 0 and 15 for CC comparisons.
> ---
>  Bootstrap and regtest or still running.  Assuming no regressions, ok
>  for {mainline,11,12,13,14}?  Would be great to see this in 14.2 RC :)

I didn't have the schedule for 11.5 RC in mind which is tomorrow and the
release a week afterwards.  I hope this is still appropriate for 11.5?

Cheers,
Stefan

> 
>  gcc/config/s390/s390.md | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
> index f5d7003dfad..d3931b09417 100644
> --- a/gcc/config/s390/s390.md
> +++ b/gcc/config/s390/s390.md
> @@ -9556,7 +9556,8 @@
>  (define_insn "*icjump_64"
>[(set (pc)
>  (if_then_else
> -  (match_operator 1 "s390_comparison" [(reg CC_REGNUM) (const_int 
> 0)])
> +  (match_operator 1 "s390_comparison" [(reg CC_REGNUM)
> +(match_operand 2 
> "const_int_operand" "")])
>(pc)
>(label_ref (match_operand 0 "" ""]
>""
> -- 
> 2.45.2
>

Re: [pve-devel] [PATCH installer 06/14] common: split out installer setup files loading functionality

On 7/10/24 15:27, Christoph Heiss wrote:
> diff --git a/proxmox-installer-common/src/setup.rs 
> b/proxmox-installer-common/src/setup.rs
> index 9131ac9..29137bf 100644
> --- a/proxmox-installer-common/src/setup.rs
> +++ b/proxmox-installer-common/src/setup.rs
> @@ -163,24 +163,29 @@ pub fn installer_setup(in_test_mode: bool) -> 
> Result<(SetupInfo, LocaleInfo, Run
>  } else {
>  crate::RUNTIME_DIR.to_owned()
>  };
> -let path = PathBuf::from(base_path);
>  
> +load_installer_setup_files(::from(base_path))
> +}
> +
> +pub fn load_installer_setup_files(
> +base_path: ,

Could use AsRef here since it's public API. In the test specific
code we could also use it for parameters, but there it's not really
important since it's not public API.


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Re: [pve-devel] [PATCH installer 10/14] auto-installer: tests: replace left/right with got/expected in output

On 7/10/24 15:27, Christoph Heiss wrote:
> Makes more sense and makes debugging easier.
> 
> Signed-off-by: Christoph Heiss 
> ---
>  proxmox-auto-installer/tests/parse-answer.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/proxmox-auto-installer/tests/parse-answer.rs 
> b/proxmox-auto-installer/tests/parse-answer.rs
> index 450915a..81079b8 100644
> --- a/proxmox-auto-installer/tests/parse-answer.rs
> +++ b/proxmox-auto-installer/tests/parse-answer.rs
> @@ -77,7 +77,7 @@ fn test_parse_answers() {
>  let compare: Value = serde_json::from_str(_raw).unwrap();
>  if config != compare {
>  panic!(
> -"Test {} failed:\nleft:  {:#?}\nright: {:#?}\n",
> +"Test {} failed:\ngot: {:#?}\nexpected: {:#?}\n",
>  name, config, compare
>  );
>  }

maybe use assert_eq!() here altogether?

Also above in the file use assert!(!runtime_info.disks.is_empty()) ?


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[ceph-users] Re: cephadm for Ubuntu 24.04

2024-07-11 Thread Stefan Kooman


On 11-07-2024 14:20, John Mulligan wrote:

On Thursday, July 11, 2024 4:22:28 AM EDT Stefan Kooman wrote:

On 11-07-2024 09:55, Malte Stroem wrote:

Hello Stefan,

have a look:

https://docs.ceph.com/en/latest/cephadm/install/#curl-based-installation


Yeah, I have read that part.


Just download cephadm. It will work on any distro.


curl --silent --remote-name --location
https://download.ceph.com/rpm-18.2.1/el9/noarch/cephadm

./cephadm gather-facts
Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in _run_code
File "/root/./cephadm/__main__.py", line 10700, in 
File "/root/./cephadm/__main__.py", line 10688, in main
File "/root/./cephadm/__main__.py", line 9772, in command_gather_facts
File "/root/./cephadm/__main__.py", line 9762, in dump
File "/root/./cephadm/__main__.py", line 9677, in kernel_security
File "/root/./cephadm/__main__.py", line 9658, in _fetch_apparmor
ValueError: too many values to unpack (expected 2)

The version that works for 22.04 also doesn't work on 24.04 and fails in
a similar way.

It just isn't that simple I'm afraid. But it _should_ be that simple,
agreed.


You do not need any ceph package like ceph-common for example to run
cephadm.


Indeed, which is pretty neat. If cephadm works you can basically do all
ceph related stuff in a container. Getting cephadm to run on more
platforms is the last mile.

Gr. Stefan



Hi there,
The traceback you are hitting is a bug - there's a fix already applied to main:
https://github.com/ceph/ceph/pull/57955


Thanks, I hadn't found that one.


I'll ask to have backport PRs get generated. I'm personally pretty clueless as
to how to process backports.


Ah, yeah, that's on my todo list as well (work on backports). AFAIK you 
need to cherry pick from main branch when processing PRs.




The bug is independent of how cephadm is packaged FWIW. Even if you had a
package of just cephadm built for ubuntu 24.04 it would have still hit the
problem. The code simply didn't understand all the possible syntax that can
appear in the apparmor profiles and newer versions of ubuntu appear to use
apparmor profiles with spaces in the name more commonly than older versions.


Ah, that explains ...




The current cephadm build process creates a "zipapp" out of a few select
python packages and the cephadm source code. If you really want to you could
wrap that, and just that, in a system package what would not need many
dependencies. However, this would need to be a bespoke package as the packages
created by the ceph project include "everything" ceph builds. But the build
script for cephadm (./src/cephadm/build.py) doesn't need any of those other
binaries to be built to work. - In case you were still curious about that and
want to tinker.


You betcha. Okay, that worked perfectly. I backported the fixes from 
#57955 in cephadm.py (apparently there was a code refactor and 
cephadmlib does not exist in 18.2.1). This worked for me:


./src/cephadm/build.py --python /usr/bin/python3 /tmp/cephadm 
-SCEPH_GIT_VER=$(git rev-parse HEAD) -SCEPH_GIT_NICE_VER=$(git describe) 
-SCEPH_RELEASE_NAME=reef -SCEPH_RELEASE_TYPE=stable


This works fine on 24.04.

Getting this in a CI/CD pipeline whenever we need a new cephadm version 
and built a proper cephadm package we can install (instead of 
downloading a binary) would certainly be an option for us. Not sure if 
we are the only ones that want cephadm installed through packages 
though. Otherwise it would warrant an upstream cephadm package IMHO.


Thanks a lot!

Gr. Stefan
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Re: [pve-devel] [PATCH installer 04/14] common: simplify filesystem type serializing & Display trait impl

On 7/10/24 15:27, Christoph Heiss wrote:
> +impl<'de> Deserialize<'de> for FsType {
> +fn deserialize(deserializer: D) -> Result
> +where
> +D: serde::Deserializer<'de>,
> +{
> +let fs: String = Deserialize::deserialize(deserializer)?;
> +
> +match fs.as_str() {
> +"ext4" => Ok(FsType::Ext4),
> +"xfs" => Ok(FsType::Xfs),
> +"zfs (RAID0)" => Ok(FsType::Zfs(ZfsRaidLevel::Raid0)),
> +"zfs (RAID1)" => Ok(FsType::Zfs(ZfsRaidLevel::Raid1)),
> +"zfs (RAID10)" => Ok(FsType::Zfs(ZfsRaidLevel::Raid10)),
> +"zfs (RAIDZ-1)" => Ok(FsType::Zfs(ZfsRaidLevel::RaidZ)),
> +"zfs (RAIDZ-2)" => Ok(FsType::Zfs(ZfsRaidLevel::RaidZ2)),
> +"zfs (RAIDZ-3)" => Ok(FsType::Zfs(ZfsRaidLevel::RaidZ3)),
> +"btrfs (RAID0)" => Ok(FsType::Btrfs(BtrfsRaidLevel::Raid0)),
> +"btrfs (RAID1)" => Ok(FsType::Btrfs(BtrfsRaidLevel::Raid1)),
> +"btrfs (RAID10)" => Ok(FsType::Btrfs(BtrfsRaidLevel::Raid10)),
> +_ => Err(serde::de::Error::custom("could not find file system: 
> {fs}")),
> +}
> +}
> +}

Maybe we could implement FromStr here and use
serde_plain::derive_deserialize_from_fromstr ?

We could even implement FromStr for BtrfsRaidLevel and ZfsRaidLevel and
then use that here, but it might be a bit overkill for just this

> +impl Serialize for FsType {
> +fn serialize(, serializer: S) -> Result
> +where
> +S: serde::Serializer,
> +{
> +let value = match self {
> +// proxinstall::$fssetup
> +FsType::Ext4 => "ext4",
> +FsType::Xfs => "xfs",
> +// proxinstall::get_zfs_raid_setup()
> +FsType::Zfs(level) => !("zfs ({level})"),
> +// proxinstall::get_btrfs_raid_setup()
> +FsType::Btrfs(level) => !("btrfs ({level})"),
> +};
> +
> +serializer.collect_str(value)
> +}
> +}

Same as above but with Display and
serde_plain::derive_display_from_serialize


___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

[PATCH] s390: Align cjump_64 and icjump_64

During machine reorg we optimize backward jumps and transform insns as
e.g.

(jump_insn 118 117 119 (set (pc)
(if_then_else (ne (reg:CCRAW 33 %cc)
(const_int 8 [0x8]))
(label_ref 134)
(pc))) "dec_math_1.f90":204:8 discrim 1 2161 {*cjump_64}
 (expr_list:REG_DEAD (reg:CCRAW 33 %cc)
(int_list:REG_BR_PROB 719407028 (nil)))
 -> 134)

into

(jump_insn 118 117 432 (set (pc)
(if_then_else (ne (reg:CCRAW 33 %cc)
(const_int 8 [0x8]))
(pc)
(label_ref 433))) "dec_math_1.f90":204:8 discrim 1 -1
 (expr_list:REG_DEAD (reg:CCRAW 33 %cc)
(int_list:REG_BR_PROB 719407028 (nil)))
 -> 433)

The latter is not recognized anymore since *icjump_64 only matches
CC_REGNUM against zero.  Fixed by aligning *cjump_64 and *icjump_64.

gcc/ChangeLog:

* config/s390/s390.md (*icjump_64): Allow raw CC comparisons,
i.e., any constant integer between 0 and 15 for CC comparisons.
---
 Bootstrap and regtest or still running.  Assuming no regressions, ok
 for {mainline,11,12,13,14}?  Would be great to see this in 14.2 RC :)

 gcc/config/s390/s390.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index f5d7003dfad..d3931b09417 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -9556,7 +9556,8 @@
 (define_insn "*icjump_64"
   [(set (pc)
 (if_then_else
-  (match_operator 1 "s390_comparison" [(reg CC_REGNUM) (const_int 0)])
+  (match_operator 1 "s390_comparison" [(reg CC_REGNUM)
+  (match_operand 2 
"const_int_operand" "")])
   (pc)
   (label_ref (match_operand 0 "" ""]
   ""
-- 
2.45.2

Re: [NonGNU-devel ELPA] Tarball build failure for vm

2024-07-11 Thread Stefan Monnier via General discussion of VM mail reader

Mark Diekhans [2024-07-10 23:02:23] wrote:
> version.texinfo is generate by the Makefile
> I don't know how ELPA builds work, so I can't advise

No worries, I'm working on it.

> Thanks so much for the work of moving VM development to Git!  Would it
> be possible to use a separate mailing list (opt-in) for automated
> build failure messages? Just a suggestion.

Those email are sent to the `Maintainer:` address.


Stefan

Re: [PATCH] test/vsock: add install target

On Thu, Jul 11, 2024 at 09:07:04AM +0200, Stefano Garzarella wrote:
> CCing Stefan.
> 
> On Wed, Jul 10, 2024 at 07:00:59PM GMT, Jakub Kicinski wrote:
> > On Wed, 10 Jul 2024 13:58:39 +0200 Stefano Garzarella wrote:
> > > There is a comment there:
> > > 
> > >  # Avoid changing the rest of the logic here and lib.mk.
> > > 
> > > Added by commit 17eac6c2db8b2cdfe33d40229bdda2acd86b304a.
> > > 
> > > IIUC they re-used INSTALL_PATH, just to avoid too many changes in that
> > > file and in tools/testing/selftests/lib.mk
> > > 
> > > So, IMHO we should not care about it and only use VSOCK_INSTALL_PATH if
> > > you don't want to conflict with INSTALL_PATH.
> > 
> > Any reason why vsock isn't part of selftests in the first place?
> > 
> 
> Usually vsock tests test both the driver (virtio-vsock) in the guest and the
> device in the host kernel (vhost-vsock). So I usually run the tests in 2
> nested VMs to test the latest changes for both the guest and the host.
> 
> I don't know enough selftests, but do you think it is possible to integrate
> them?
> 
> CCing Stefan who is the original author and may remember more reasons about
> this choice.

It's probably because of the manual steps in tools/testing/vsock/README:

  The following prerequisite steps are not automated and must be performed prior
  to running tests:

  1. Build the kernel, make headers_install, and build these tests.
  2. Install the kernel and tests on the host.
  3. Install the kernel and tests inside the guest.
  4. Boot the guest and ensure that the AF_VSOCK transport is enabled.

If you want to automate this for QEMU, VMware, and Hyper-V that would be
great. It relies on having a guest running under these hypervisors and
that's not trivial to automate (plus it involves proprietary software
for VMware and Hyper-V that may not be available without additional
license agreements and/or payment).

Stefan

signature.asc
Description: PGP signature

Re: [PATCH v8 09/10] hw/nvme: add reservation protocal command

On Tue, Jul 09, 2024 at 10:47:05AM +0800, Changqi Lu wrote:
> Add reservation acquire, reservation register,
> reservation release and reservation report commands
> in the nvme device layer.
> 
> By introducing these commands, this enables the nvme
> device to perform reservation-related tasks, including
> querying keys, querying reservation status, registering
> reservation keys, initiating and releasing reservations,
> as well as clearing and preempting reservations held by
> other keys.
> 
> These commands are crucial for management and control of
> shared storage resources in a persistent manner.
> Signed-off-by: Changqi Lu 
> Signed-off-by: zhenwei pi 
> Acked-by: Klaus Jensen 
> ---
>  hw/nvme/ctrl.c   | 323 ++-
>  hw/nvme/nvme.h   |   4 +
>  include/block/nvme.h |  37 +
>  3 files changed, 363 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
> index ad212de723..a69a499078 100644
> --- a/hw/nvme/ctrl.c
> +++ b/hw/nvme/ctrl.c
> @@ -294,6 +294,10 @@ static const uint32_t nvme_cse_iocs_nvm[256] = {
>  [NVME_CMD_COMPARE]  = NVME_CMD_EFF_CSUPP,
>  [NVME_CMD_IO_MGMT_RECV] = NVME_CMD_EFF_CSUPP,
>  [NVME_CMD_IO_MGMT_SEND] = NVME_CMD_EFF_CSUPP | NVME_CMD_EFF_LBCC,
> +[NVME_CMD_RESV_REGISTER]= NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_REPORT]  = NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_ACQUIRE] = NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_RELEASE] = NVME_CMD_EFF_CSUPP,
>  };
>  
>  static const uint32_t nvme_cse_iocs_zoned[256] = {
> @@ -308,6 +312,10 @@ static const uint32_t nvme_cse_iocs_zoned[256] = {
>  [NVME_CMD_ZONE_APPEND]  = NVME_CMD_EFF_CSUPP | NVME_CMD_EFF_LBCC,
>  [NVME_CMD_ZONE_MGMT_SEND]   = NVME_CMD_EFF_CSUPP | NVME_CMD_EFF_LBCC,
>  [NVME_CMD_ZONE_MGMT_RECV]   = NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_REGISTER]= NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_REPORT]  = NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_ACQUIRE] = NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_RELEASE] = NVME_CMD_EFF_CSUPP,
>  };
>  
>  static void nvme_process_sq(void *opaque);
> @@ -1745,6 +1753,7 @@ static void nvme_aio_err(NvmeRequest *req, int ret)
>  
>  switch (req->cmd.opcode) {
>  case NVME_CMD_READ:
> +case NVME_CMD_RESV_REPORT:
>  status = NVME_UNRECOVERED_READ;
>  break;
>  case NVME_CMD_FLUSH:
> @@ -1752,6 +1761,9 @@ static void nvme_aio_err(NvmeRequest *req, int ret)
>  case NVME_CMD_WRITE_ZEROES:
>  case NVME_CMD_ZONE_APPEND:
>  case NVME_CMD_COPY:
> +case NVME_CMD_RESV_REGISTER:
> +case NVME_CMD_RESV_ACQUIRE:
> +case NVME_CMD_RESV_RELEASE:
>  status = NVME_WRITE_FAULT;
>  break;
>  default:
> @@ -2127,7 +2139,10 @@ static inline bool nvme_is_write(NvmeRequest *req)
>  
>  return rw->opcode == NVME_CMD_WRITE ||
> rw->opcode == NVME_CMD_ZONE_APPEND ||
> -   rw->opcode == NVME_CMD_WRITE_ZEROES;
> +   rw->opcode == NVME_CMD_WRITE_ZEROES ||
> +   rw->opcode == NVME_CMD_RESV_REGISTER ||
> +   rw->opcode == NVME_CMD_RESV_ACQUIRE ||
> +   rw->opcode == NVME_CMD_RESV_RELEASE;
>  }

Why is this change necessary? The only nvme_is_write() caller I see is:

  void nvme_rw_complete_cb(void *opaque, int ret)
  {
  ...
  if (ns->params.zoned && nvme_is_write(req)) {
  nvme_finalize_zoned_write(ns, req);
  }

nvme_finalize_zoned_write() must not be called on reservation requests
because they don't use NvmeRwCmd:

  static void nvme_finalize_zoned_write(NvmeNamespace *ns, NvmeRequest *req)
  {
  NvmeRwCmd *rw = (NvmeRwCmd *)>cmd;


signature.asc
Description: PGP signature

Re: [PATCH v8 09/10] hw/nvme: add reservation protocal command

On Tue, Jul 09, 2024 at 10:47:05AM +0800, Changqi Lu wrote:
> Add reservation acquire, reservation register,
> reservation release and reservation report commands
> in the nvme device layer.
> 
> By introducing these commands, this enables the nvme
> device to perform reservation-related tasks, including
> querying keys, querying reservation status, registering
> reservation keys, initiating and releasing reservations,
> as well as clearing and preempting reservations held by
> other keys.
> 
> These commands are crucial for management and control of
> shared storage resources in a persistent manner.
> Signed-off-by: Changqi Lu 
> Signed-off-by: zhenwei pi 
> Acked-by: Klaus Jensen 
> ---
>  hw/nvme/ctrl.c   | 323 ++-
>  hw/nvme/nvme.h   |   4 +
>  include/block/nvme.h |  37 +
>  3 files changed, 363 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
> index ad212de723..a69a499078 100644
> --- a/hw/nvme/ctrl.c
> +++ b/hw/nvme/ctrl.c
> @@ -294,6 +294,10 @@ static const uint32_t nvme_cse_iocs_nvm[256] = {
>  [NVME_CMD_COMPARE]  = NVME_CMD_EFF_CSUPP,
>  [NVME_CMD_IO_MGMT_RECV] = NVME_CMD_EFF_CSUPP,
>  [NVME_CMD_IO_MGMT_SEND] = NVME_CMD_EFF_CSUPP | NVME_CMD_EFF_LBCC,
> +[NVME_CMD_RESV_REGISTER]= NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_REPORT]  = NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_ACQUIRE] = NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_RELEASE] = NVME_CMD_EFF_CSUPP,
>  };
>  
>  static const uint32_t nvme_cse_iocs_zoned[256] = {
> @@ -308,6 +312,10 @@ static const uint32_t nvme_cse_iocs_zoned[256] = {
>  [NVME_CMD_ZONE_APPEND]  = NVME_CMD_EFF_CSUPP | NVME_CMD_EFF_LBCC,
>  [NVME_CMD_ZONE_MGMT_SEND]   = NVME_CMD_EFF_CSUPP | NVME_CMD_EFF_LBCC,
>  [NVME_CMD_ZONE_MGMT_RECV]   = NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_REGISTER]= NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_REPORT]  = NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_ACQUIRE] = NVME_CMD_EFF_CSUPP,
> +[NVME_CMD_RESV_RELEASE] = NVME_CMD_EFF_CSUPP,
>  };
>  
>  static void nvme_process_sq(void *opaque);
> @@ -1745,6 +1753,7 @@ static void nvme_aio_err(NvmeRequest *req, int ret)
>  
>  switch (req->cmd.opcode) {
>  case NVME_CMD_READ:
> +case NVME_CMD_RESV_REPORT:
>  status = NVME_UNRECOVERED_READ;
>  break;
>  case NVME_CMD_FLUSH:
> @@ -1752,6 +1761,9 @@ static void nvme_aio_err(NvmeRequest *req, int ret)
>  case NVME_CMD_WRITE_ZEROES:
>  case NVME_CMD_ZONE_APPEND:
>  case NVME_CMD_COPY:
> +case NVME_CMD_RESV_REGISTER:
> +case NVME_CMD_RESV_ACQUIRE:
> +case NVME_CMD_RESV_RELEASE:
>  status = NVME_WRITE_FAULT;
>  break;
>  default:
> @@ -2127,7 +2139,10 @@ static inline bool nvme_is_write(NvmeRequest *req)
>  
>  return rw->opcode == NVME_CMD_WRITE ||
> rw->opcode == NVME_CMD_ZONE_APPEND ||
> -   rw->opcode == NVME_CMD_WRITE_ZEROES;
> +   rw->opcode == NVME_CMD_WRITE_ZEROES ||
> +   rw->opcode == NVME_CMD_RESV_REGISTER ||
> +   rw->opcode == NVME_CMD_RESV_ACQUIRE ||
> +   rw->opcode == NVME_CMD_RESV_RELEASE;
>  }

Why is this change necessary? The only nvme_is_write() caller I see is:

  void nvme_rw_complete_cb(void *opaque, int ret)
  {
  ...
  if (ns->params.zoned && nvme_is_write(req)) {
  nvme_finalize_zoned_write(ns, req);
  }

nvme_finalize_zoned_write() must not be called on reservation requests
because they don't use NvmeRwCmd:

  static void nvme_finalize_zoned_write(NvmeNamespace *ns, NvmeRequest *req)
  {
  NvmeRwCmd *rw = (NvmeRwCmd *)>cmd;


signature.asc
Description: PGP signature

[SCM] Samba Shared Repository - branch v4-19-test updated

2024-07-11 Thread Stefan Metzmacher

The branch, v4-19-test has been updated
   via  63c8ed2a386 .gitlab-ci-main.yml: Add safe.directory '*'
   via  b22c93aca20 gitlab-ci: Also add the git directory for pipeline in 
the main mirror
  from  8d08c814134 third_party/heimdal: Import 
lorikeet-heimdal-202407041740 (commit 42ba2a6e5dd1bc14a8b5ada8c9b8ace85956f6a0)

https://git.samba.org/?p=samba.git;a=shortlog;h=v4-19-test


- Log -
commit 63c8ed2a38699e9f3e6f10dc2ba4e6c2904af5a1
Author: Pavel Filipenský 
Date:   Thu Jul 4 11:08:03 2024 +0200

.gitlab-ci-main.yml: Add safe.directory '*'

This is to fix the error when pushing to personal gitlab repo:

2024-07-04 08:16:05,460 Running: 'git clone --recursive --shared 
/builds/pfilipen/samba /builds/samba-testbase/master' in 
'/builds/pfilipen/samba'
Cloning into '/builds/samba-testbase/master'...
fatal: detected dubious ownership in repository at 
'/builds/pfilipen/samba/.git'
To add an exception for this directory, call:
git config --global --add safe.directory /builds/pfilipen/samba/.git
fatal: Could not read from remote repository.

Instead of adding more and more explicit repositories
we should just allow any, we're in an isolated environment...

BUG: https://bugzilla.samba.org/show_bug.cgi?id=15660

Pair-Programmed-With: Stefan Metzmacher 
Signed-off-by: Pavel Filipenský 
Signed-off-by: Stefan Metzmacher 
Reviewed-by: Andreas Schneider 

Autobuild-User(master): Stefan Metzmacher 
Autobuild-Date(master): Wed Jul 10 10:35:00 UTC 2024 on atb-devel-224

(cherry picked from commit 3a21b7d9a4e7e9814d0be8c0ebf72b9821a5dc36)

Autobuild-User(v4-19-test): Stefan Metzmacher 
Autobuild-Date(v4-19-test): Thu Jul 11 13:22:43 UTC 2024 on atb-devel-224

commit b22c93aca200c6ebfcacf0795fbf207dc59dc717
Author: Andreas Schneider 
Date:   Wed Jul 3 13:05:51 2024 +0200

gitlab-ci: Also add the git directory for pipeline in the main mirror

Signed-off-by: Andreas Schneider 
Reviewed-by: Jo Sutton 

Autobuild-User(master): Andreas Schneider 
Autobuild-Date(master): Thu Jul  4 08:08:49 UTC 2024 on atb-devel-224

(cherry picked from commit 93a3dd48d66786cb8765d3ce84ca9f3ad419ac88)

---

Summary of changes:
 .gitlab-ci-main.yml | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)


Changeset truncated at 500 lines:

diff --git a/.gitlab-ci-main.yml b/.gitlab-ci-main.yml
index 1bf4dd0da17..f7dfe890032 100644
--- a/.gitlab-ci-main.yml
+++ b/.gitlab-ci-main.yml
@@ -146,8 +146,7 @@ include:
 - ccache -z -M 500M
 - ccache -s
   # We are already running .gitlab-ci directives from this repo, remove 
additional checks that break our CI
-- git config --global --add safe.directory `pwd`
-- git config --global --add safe.directory 
/builds/samba-team/devel/samba/.git
+- git config --global --add safe.directory '*'
   after_script:
 - mount
 - df -h


-- 
Samba Shared Repository

Re: [PATCH v8 10/10] block/iscsi: add persistent reservation in/out driver

On Tue, Jul 09, 2024 at 10:47:06AM +0800, Changqi Lu wrote:
> Add persistent reservation in/out operations for iscsi driver.
> The following methods are implemented: bdrv_co_pr_read_keys,
> bdrv_co_pr_read_reservation, bdrv_co_pr_register, bdrv_co_pr_reserve,
> bdrv_co_pr_release, bdrv_co_pr_clear and bdrv_co_pr_preempt.
> 
> Signed-off-by: Changqi Lu 
> Signed-off-by: zhenwei pi 
> ---
>  block/iscsi.c | 425 ++
>  1 file changed, 425 insertions(+)

Aside from the g_free() issue I commented on:

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PATCH v8 10/10] block/iscsi: add persistent reservation in/out driver

On Tue, Jul 09, 2024 at 10:47:06AM +0800, Changqi Lu wrote:
> Add persistent reservation in/out operations for iscsi driver.
> The following methods are implemented: bdrv_co_pr_read_keys,
> bdrv_co_pr_read_reservation, bdrv_co_pr_register, bdrv_co_pr_reserve,
> bdrv_co_pr_release, bdrv_co_pr_clear and bdrv_co_pr_preempt.
> 
> Signed-off-by: Changqi Lu 
> Signed-off-by: zhenwei pi 
> ---
>  block/iscsi.c | 425 ++
>  1 file changed, 425 insertions(+)

Aside from the g_free() issue I commented on:

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PATCH v8 10/10] block/iscsi: add persistent reservation in/out driver

On Tue, Jul 09, 2024 at 10:47:06AM +0800, Changqi Lu wrote:
> Add persistent reservation in/out operations for iscsi driver.
> The following methods are implemented: bdrv_co_pr_read_keys,
> bdrv_co_pr_read_reservation, bdrv_co_pr_register, bdrv_co_pr_reserve,
> bdrv_co_pr_release, bdrv_co_pr_clear and bdrv_co_pr_preempt.
> 
> Signed-off-by: Changqi Lu 
> Signed-off-by: zhenwei pi 
> ---
>  block/iscsi.c | 425 ++
>  1 file changed, 425 insertions(+)
> 
> diff --git a/block/iscsi.c b/block/iscsi.c
> index 2ff14b7472..ba51f6d016 100644
> --- a/block/iscsi.c
> +++ b/block/iscsi.c
> @@ -96,6 +96,7 @@ typedef struct IscsiLun {
>  unsigned long *allocmap_valid;
>  long allocmap_size;
>  int cluster_size;
> +uint8_t pr_cap;
>  bool use_16_for_rw;
>  bool write_protected;
>  bool lbpme;
> @@ -280,6 +281,10 @@ iscsi_co_generic_cb(struct iscsi_context *iscsi, int 
> status,
>  iTask->err_code = -error;
>  iTask->err_str = g_strdup(iscsi_get_error(iscsi));
>  }
> +} else if (status == SCSI_STATUS_RESERVATION_CONFLICT) {
> +iTask->err_code = -EBADE;
> +error_report("iSCSI Persistent Reservation Conflict: %s",
> + iscsi_get_error(iscsi));
>  }
>  }
>  }
> @@ -1792,6 +1797,50 @@ static void iscsi_save_designator(IscsiLun *lun,
>  }
>  }
>  
> +/*
> + *  Ensure iscsi_open() must succeed, weather or not the target
> + *  implement SCSI_PR_IN_REPORT_CAPABILITIES.
> + */
> +static void iscsi_get_pr_cap_sync(IscsiLun *iscsilun)
> +{
> +struct scsi_task *task = NULL;
> +struct scsi_persistent_reserve_in_report_capabilities *rc = NULL;
> +int retries = ISCSI_CMD_RETRIES;
> +int xferlen = sizeof(struct 
> scsi_persistent_reserve_in_report_capabilities);
> +
> +do {
> +if (task != NULL) {
> +scsi_free_scsi_task(task);
> +task = NULL;
> +}
> +
> +task = iscsi_persistent_reserve_in_sync(iscsilun->iscsi,
> +   iscsilun->lun, SCSI_PR_IN_REPORT_CAPABILITIES, xferlen);
> +if (task != NULL && task->status == SCSI_STATUS_GOOD) {
> +rc = scsi_datain_unmarshall(task);
> +if (rc == NULL) {
> +error_report("iSCSI: Failed to unmarshall "
> + "report capabilities data.");
> +} else {
> +iscsilun->pr_cap =
> +
> scsi_pr_cap_to_block(rc->persistent_reservation_type_mask);
> +iscsilun->pr_cap |= (rc->ptpl_a) ? BLK_PR_CAP_PTPL : 0;
> +}
> +break;
> +}
> +} while (task != NULL && task->status == SCSI_STATUS_CHECK_CONDITION
> + && task->sense.key == SCSI_SENSE_UNIT_ATTENTION
> + && retries-- > 0);
> +
> +if (task == NULL || task->status != SCSI_STATUS_GOOD) {
> +error_report("iSCSI: failed to send report capabilities command.");
> +}
> +
> +if (task) {
> +scsi_free_scsi_task(task);
> +}
> +}
> +
>  static int iscsi_open(BlockDriverState *bs, QDict *options, int flags,
>Error **errp)
>  {
> @@ -2024,6 +2073,7 @@ static int iscsi_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  bs->supported_zero_flags = BDRV_REQ_MAY_UNMAP;
>  }
>  
> +iscsi_get_pr_cap_sync(iscsilun);
>  out:
>  qemu_opts_del(opts);
>  g_free(initiator_name);
> @@ -2110,6 +2160,8 @@ static void iscsi_refresh_limits(BlockDriverState *bs, 
> Error **errp)
>  bs->bl.opt_transfer = pow2floor(iscsilun->bl.opt_xfer_len *
>  iscsilun->block_size);
>  }
> +
> +bs->bl.pr_cap = iscsilun->pr_cap;
>  }
>  
>  /* Note that this will not re-establish a connection with an iSCSI target - 
> it
> @@ -2408,6 +2460,371 @@ out_unlock:
>  return r;
>  }
>  
> +static int coroutine_fn
> +iscsi_co_pr_read_keys(BlockDriverState *bs, uint32_t *generation,
> +  uint32_t num_keys, uint64_t *keys)
> +{
> +IscsiLun *iscsilun = bs->opaque;
> +QEMUIOVector qiov;
> +struct IscsiTask iTask;
> +int xferlen = sizeof(struct scsi_persistent_reserve_in_read_keys) +
> +  sizeof(uint64_t) * num_keys;
> +g_autofree uint8_t *buf = g_malloc0(xferlen);
> +int32_t num_collect_keys = 0;
> +int r = 0;
> +
> +qemu_iovec_init_buf(, buf, xferlen);
> +iscsi_co_init_iscsitask(iscsilun, );
> +qemu_mutex_lock(>mutex);
> +retry:
> +iTask.task = iscsi_persistent_reserve_in_task(iscsilun->iscsi,
> + iscsilun->lun, SCSI_PR_IN_READ_KEYS, xferlen,
> + iscsi_co_generic_cb, );
> +
> +if (iTask.task == NULL) {
> +qemu_mutex_unlock(>mutex);
> +return -ENOMEM;
> +}
> +
> +scsi_task_set_iov_in(iTask.task, (struct scsi_iovec

Re: [PATCH v8 10/10] block/iscsi: add persistent reservation in/out driver

On Tue, Jul 09, 2024 at 10:47:06AM +0800, Changqi Lu wrote:
> Add persistent reservation in/out operations for iscsi driver.
> The following methods are implemented: bdrv_co_pr_read_keys,
> bdrv_co_pr_read_reservation, bdrv_co_pr_register, bdrv_co_pr_reserve,
> bdrv_co_pr_release, bdrv_co_pr_clear and bdrv_co_pr_preempt.
> 
> Signed-off-by: Changqi Lu 
> Signed-off-by: zhenwei pi 
> ---
>  block/iscsi.c | 425 ++
>  1 file changed, 425 insertions(+)
> 
> diff --git a/block/iscsi.c b/block/iscsi.c
> index 2ff14b7472..ba51f6d016 100644
> --- a/block/iscsi.c
> +++ b/block/iscsi.c
> @@ -96,6 +96,7 @@ typedef struct IscsiLun {
>  unsigned long *allocmap_valid;
>  long allocmap_size;
>  int cluster_size;
> +uint8_t pr_cap;
>  bool use_16_for_rw;
>  bool write_protected;
>  bool lbpme;
> @@ -280,6 +281,10 @@ iscsi_co_generic_cb(struct iscsi_context *iscsi, int 
> status,
>  iTask->err_code = -error;
>  iTask->err_str = g_strdup(iscsi_get_error(iscsi));
>  }
> +} else if (status == SCSI_STATUS_RESERVATION_CONFLICT) {
> +iTask->err_code = -EBADE;
> +error_report("iSCSI Persistent Reservation Conflict: %s",
> + iscsi_get_error(iscsi));
>  }
>  }
>  }
> @@ -1792,6 +1797,50 @@ static void iscsi_save_designator(IscsiLun *lun,
>  }
>  }
>  
> +/*
> + *  Ensure iscsi_open() must succeed, weather or not the target
> + *  implement SCSI_PR_IN_REPORT_CAPABILITIES.
> + */
> +static void iscsi_get_pr_cap_sync(IscsiLun *iscsilun)
> +{
> +struct scsi_task *task = NULL;
> +struct scsi_persistent_reserve_in_report_capabilities *rc = NULL;
> +int retries = ISCSI_CMD_RETRIES;
> +int xferlen = sizeof(struct 
> scsi_persistent_reserve_in_report_capabilities);
> +
> +do {
> +if (task != NULL) {
> +scsi_free_scsi_task(task);
> +task = NULL;
> +}
> +
> +task = iscsi_persistent_reserve_in_sync(iscsilun->iscsi,
> +   iscsilun->lun, SCSI_PR_IN_REPORT_CAPABILITIES, xferlen);
> +if (task != NULL && task->status == SCSI_STATUS_GOOD) {
> +rc = scsi_datain_unmarshall(task);
> +if (rc == NULL) {
> +error_report("iSCSI: Failed to unmarshall "
> + "report capabilities data.");
> +} else {
> +iscsilun->pr_cap =
> +
> scsi_pr_cap_to_block(rc->persistent_reservation_type_mask);
> +iscsilun->pr_cap |= (rc->ptpl_a) ? BLK_PR_CAP_PTPL : 0;
> +}
> +break;
> +}
> +} while (task != NULL && task->status == SCSI_STATUS_CHECK_CONDITION
> + && task->sense.key == SCSI_SENSE_UNIT_ATTENTION
> + && retries-- > 0);
> +
> +if (task == NULL || task->status != SCSI_STATUS_GOOD) {
> +error_report("iSCSI: failed to send report capabilities command.");
> +}
> +
> +if (task) {
> +scsi_free_scsi_task(task);
> +}
> +}
> +
>  static int iscsi_open(BlockDriverState *bs, QDict *options, int flags,
>Error **errp)
>  {
> @@ -2024,6 +2073,7 @@ static int iscsi_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  bs->supported_zero_flags = BDRV_REQ_MAY_UNMAP;
>  }
>  
> +iscsi_get_pr_cap_sync(iscsilun);
>  out:
>  qemu_opts_del(opts);
>  g_free(initiator_name);
> @@ -2110,6 +2160,8 @@ static void iscsi_refresh_limits(BlockDriverState *bs, 
> Error **errp)
>  bs->bl.opt_transfer = pow2floor(iscsilun->bl.opt_xfer_len *
>  iscsilun->block_size);
>  }
> +
> +bs->bl.pr_cap = iscsilun->pr_cap;
>  }
>  
>  /* Note that this will not re-establish a connection with an iSCSI target - 
> it
> @@ -2408,6 +2460,371 @@ out_unlock:
>  return r;
>  }
>  
> +static int coroutine_fn
> +iscsi_co_pr_read_keys(BlockDriverState *bs, uint32_t *generation,
> +  uint32_t num_keys, uint64_t *keys)
> +{
> +IscsiLun *iscsilun = bs->opaque;
> +QEMUIOVector qiov;
> +struct IscsiTask iTask;
> +int xferlen = sizeof(struct scsi_persistent_reserve_in_read_keys) +
> +  sizeof(uint64_t) * num_keys;
> +g_autofree uint8_t *buf = g_malloc0(xferlen);
> +int32_t num_collect_keys = 0;
> +int r = 0;
> +
> +qemu_iovec_init_buf(, buf, xferlen);
> +iscsi_co_init_iscsitask(iscsilun, );
> +qemu_mutex_lock(>mutex);
> +retry:
> +iTask.task = iscsi_persistent_reserve_in_task(iscsilun->iscsi,
> + iscsilun->lun, SCSI_PR_IN_READ_KEYS, xferlen,
> + iscsi_co_generic_cb, );
> +
> +if (iTask.task == NULL) {
> +qemu_mutex_unlock(>mutex);
> +return -ENOMEM;
> +}
> +
> +scsi_task_set_iov_in(iTask.task, (struct scsi_iovec

Re: [PATCH v8 08/10] hw/nvme: enable ONCS and rescap function

On Tue, Jul 09, 2024 at 10:47:04AM +0800, Changqi Lu wrote:
> This commit enables ONCS to support the reservation
> function at the controller level. Also enables rescap
> function in the namespace by detecting the supported reservation
> function in the backend driver.
> 
> Reviewed-by: Klaus Jensen 
> Signed-off-by: Changqi Lu 
> Signed-off-by: zhenwei pi 
> ---
>  hw/nvme/ctrl.c   | 3 ++-
>  hw/nvme/ns.c | 5 +
>  include/block/nvme.h | 2 +-
>  3 files changed, 8 insertions(+), 2 deletions(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PATCH v8 05/10] hw/scsi: add persistent reservation in/out api for scsi device

On Tue, Jul 09, 2024 at 10:47:01AM +0800, Changqi Lu wrote:
> Add persistent reservation in/out operations in the
> SCSI device layer. By introducing the persistent
> reservation in/out api, this enables the SCSI device
> to perform reservation-related tasks, including querying
> keys, querying reservation status, registering reservation
> keys, initiating and releasing reservations, as well as
> clearing and preempting reservations held by other keys.
> 
> These operations are crucial for management and control of
> shared storage resources in a persistent manner.
> 
> Signed-off-by: Changqi Lu 
> Signed-off-by: zhenwei pi 
> ---
>  hw/scsi/scsi-disk.c | 368 
>  1 file changed, 368 insertions(+)

Paolo: Please review this patch, I'm not familiar enough with hw/scsi/.

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PATCH v8 05/10] hw/scsi: add persistent reservation in/out api for scsi device

On Tue, Jul 09, 2024 at 10:47:01AM +0800, Changqi Lu wrote:
> Add persistent reservation in/out operations in the
> SCSI device layer. By introducing the persistent
> reservation in/out api, this enables the SCSI device
> to perform reservation-related tasks, including querying
> keys, querying reservation status, registering reservation
> keys, initiating and releasing reservations, as well as
> clearing and preempting reservations held by other keys.
> 
> These operations are crucial for management and control of
> shared storage resources in a persistent manner.
> 
> Signed-off-by: Changqi Lu 
> Signed-off-by: zhenwei pi 
> ---
>  hw/scsi/scsi-disk.c | 368 
>  1 file changed, 368 insertions(+)

Paolo: Please review this patch, I'm not familiar enough with hw/scsi/.

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PATCH v8 08/10] hw/nvme: enable ONCS and rescap function