dahdi-linux icon indicating copy to clipboard operation
dahdi-linux copied to clipboard

In Rocky Linux 9.2 got compilation failures related with PDE_DATA

Open rodolfojcj opened this issue 2 years ago • 8 comments

When using either the DAHDI linux complete 3.2.0 tar.gz file or the master branch sources, trying to compile on Rocky Linux 9.2 fails with error messages like these (not necessarily all of them at the same attempt):

linux/drivers/dahdi/xpp/xbus-core.c:1842:50: error: implicit declaration of function ‘PDE_DATA’; did you mean ‘NODE_DATA’? [-Werror=implicit-function-declaration]
1842 |         return single_open(file, xbus_proc_show, PDE_DATA(inode));
                                                        ^~~~~~~~
|                                                       NODE_DATA

Or

linux/drivers/dahdi/xpp/xbus-core.c:1842:50: warning: passing argument 3 of ‘single_open’ makes pointer from integer without a cast [-Wint-conversion]
1842 |         return single_open(file, xbus_proc_show, PDE_DATA(inode));
|                                                       ^~~~~~~~~~~~~~~
|                                                       |
|                                                       int

Or

linux/drivers/dahdi/xpp/xbus-core.c:1949:28: warning: assignment to ‘void *’ from ‘ int’ makes pointer from integer without a cast [-Wint-conversion]
1949 |         file->private_data = PDE_DATA(inode);

rodolfojcj avatar Sep 25 '23 00:09 rodolfojcj

The attached file dahdi-linux-issue-37-fix-24sept2023.zip has a possible fix to this issue.

I tested it with:

  • Ubuntu 23.04, kernel 6.2.0-20-generic
  • Ubuntu 22.10, kernel 5.19.0-43-generic
  • Ubuntu 22.04, kernel 5.15.0-73-generic
  • Ubuntu 20.04, kernel 5.4.0-150-generic
  • Ubuntu 18.04, kernel 4.15.0-212-generic
  • Ubuntu 16.04, kernel 4.4.0-210-generic
  • Debian 12, kernel 6.1.0-10-amd64
  • Debian 11, kernel 5.10.0-23-amd64
  • Debian 10, kernel 4.19.0-24-amd64
  • CentOS 7.9.2009 3.10.0-1160.95.1.el7.x86_64
  • Rocky Linux 9.2, kernel 5.14.0-284.25.1.el9_2.x86_64
  • Rocky Linux 8.8, kernel 4.18.0-477.21.1.el8_8.x86_64

In all those cases the compilation is successful.

Thanks in advance for any developer of this project that may review and possibly apply this fix for the master branch.

rodolfojcj avatar Sep 25 '23 00:09 rodolfojcj

@push143smart Seems like this issue was addressed in https://github.com/asterisk/dahdi-linux/commit/08fda500eda8893fddb269e07e3b1eaafd0a684b and can be closed.

InterLinked1 avatar Sep 18 '24 12:09 InterLinked1

Hello @InterLinked1 and @push143smart . Last week I found that the most recent unreleased dahdi-linux sources failed in Rocky Linux 8.10 because of wrong quantity of parameters passed to the netif_napi_add function, which is defined next to the PDE_DATA function. To solve that, I used a manual patch like this:

--- original/linux/include/dahdi/kernel.h       2024-09-12 04:07:14.000000000 +0000
+++ modified/linux/include/dahdi/kernel.h       2024-09-12 04:37:45.849184105 +0000
@@ -1557,6 +1557,8 @@
               RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9,1)
 #define netif_napi_add netif_napi_add_weight
 #define PDE_DATA(i)     pde_data(i)
+#elif defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(8,10)
+#define netif_napi_add netif_napi_add_weight
 #endif
 #endif

I don't know which Rocky Linux versions <= 8.9, if any, will also benefit from a patch like that.

Would you like to apply that change, or an equivalent one, to the official dahdi-linux sources, please?

Thank you.

rodolfojcj avatar Sep 18 '24 13:09 rodolfojcj

Hello @InterLinked1 and @push143smart . Last week I found that the most recent unreleased dahdi-linux sources failed in Rocky Linux 8.10 because of wrong quantity of parameters passed to the netif_napi_add function, which is defined next to the PDE_DATA function. To solve that, I used a manual patch like this:

--- original/linux/include/dahdi/kernel.h       2024-09-12 04:07:14.000000000 +0000
+++ modified/linux/include/dahdi/kernel.h       2024-09-12 04:37:45.849184105 +0000
@@ -1557,6 +1557,8 @@
               RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9,1)
 #define netif_napi_add netif_napi_add_weight
 #define PDE_DATA(i)     pde_data(i)
+#elif defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(8,10)
+#define netif_napi_add netif_napi_add_weight
 #endif
 #endif

I don't know which Rocky Linux versions <= 8.9, if any, will also benefit from a patch like that.

Would you like to apply that change, or an equivalent one, to the official dahdi-linux sources, please?

Thank you.

Isn't this what you've already opened an issue for here? https://github.com/asterisk/dahdi-linux/issues/38 If so, could we continue the discussion on that issue, to keep all the notes in one place? The repo's already kind of a mess and I'm trying to clean it up a bit.

In general though, the project doesn't accept patches that are posted in an issue, you would want to sign the CLA, and then submit a PR with your patch so it can be reviewed then the maintainer can merge it.

InterLinked1 avatar Sep 18 '24 21:09 InterLinked1

Hi @InterLinked1. Yes, it seems to be the same. Given that almost a year passed since I opened it, I did not remember it and found it again. On the other hand, where that CLA can be signed? Alternatively, I would be OK if someone takes that patch, apply it and publish it, so that the needed fixes are available to everyone. Regards.

rodolfojcj avatar Sep 19 '24 02:09 rodolfojcj

Hi @InterLinked1. Yes, it seems to be the same. Given that almost a year passed since I opened it, I did not remember it and found it again. On the other hand, where that CLA can be signed? Alternatively, I would be OK if someone takes that patch, apply it and publish it, so that the needed fixes are available to everyone. Regards.

I've been trying to look into this (and am in the process of trying to reconcile some of these, at least for PhreakScript), but since @push143smart has merged some of these changes with differing version numbers, new patches will be need to be created to fix those issues. I was able to reproduce a build failure on RHEL 8.9, but I don't test on RHEL very often because frankly it's a huge pain in the rear end. You seem to have pretty good awareness of exactly which versions have these changes.

If you create a PR, you should see the CLA come up as part of that. I am not sure if there is a way to do that outside of the PR process.

What I would recommend is maybe seeing if you can submit a single PR for all the various RHEL fixes based on what's currently in the tree, if you're able. It's changed slightly since you submitted these issues because @push143smart basically ignored several issues and PRs and made his own commits with different version numbers.

InterLinked1 avatar Sep 19 '24 02:09 InterLinked1

Hi @InterLinked1. Yes, it seems to be the same. Given that almost a year passed since I opened it, I did not remember it and found it again. On the other hand, where that CLA can be signed? Alternatively, I would be OK if someone takes that patch, apply it and publish it, so that the needed fixes are available to everyone. Regards.

I've been trying to look into this (and am in the process of trying to reconcile some of these, at least for PhreakScript), but since @push143smart has merged some of these changes with differing version numbers, new patches will be need to be created to fix those issues. I was able to reproduce a build failure on RHEL 8.9, but I don't test on RHEL very often because frankly it's a huge pain in the rear end. You seem to have pretty good awareness of exactly which versions have these changes.

If you create a PR, you should see the CLA come up as part of that. I am not sure if there is a way to do that outside of the PR process.

What I would recommend is maybe seeing if you can submit a single PR for all the various RHEL fixes based on what's currently in the tree, if you're able. It's changed slightly since you submitted these issues because @push143smart basically ignored several issues and PRs and made his own commits with different version numbers.

@rodolfojcj Okay, I had some time to go through this and sort it out today - I can submit a PR for the changes that need to be made. Thanks for raising these for attention.

InterLinked1 avatar Sep 19 '24 22:09 InterLinked1

Hello @InterLinked1 and @push143smart . Last week I found that the most recent unreleased dahdi-linux sources failed in Rocky Linux 8.10 because of wrong quantity of parameters passed to the netif_napi_add function, which is defined next to the PDE_DATA function. To solve that, I used a manual patch like this:

--- original/linux/include/dahdi/kernel.h       2024-09-12 04:07:14.000000000 +0000
+++ modified/linux/include/dahdi/kernel.h       2024-09-12 04:37:45.849184105 +0000
@@ -1557,6 +1557,8 @@
               RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9,1)
 #define netif_napi_add netif_napi_add_weight
 #define PDE_DATA(i)     pde_data(i)
+#elif defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(8,10)
+#define netif_napi_add netif_napi_add_weight
 #endif
 #endif

I don't know which Rocky Linux versions <= 8.9, if any, will also benefit from a patch like that.

Would you like to apply that change, or an equivalent one, to the official dahdi-linux sources, please?

Thank you.

So your original patch was for >= 8.8 and that indeed is an issue on 8.9 so I'd say the original patch you proposed a year ago is correct.

I've submitted an updated patch for the remaining RHEL issues here: https://github.com/asterisk/dahdi-linux/pull/57

@push143smart This issue itself was actually resolved so you can still go ahead and close it.

InterLinked1 avatar Sep 19 '24 22:09 InterLinked1