From: Greg Kroah-Hartman <[email protected]>
Nothing like having a very generic global variable in a tiny driver
subsystem to make a mess of the global namespace...
Note, there are many other "generic" named global variables in the drbd
subsystem, someone should fix those up one day before they hit a linking
error.
Cc: Philipp Reisner <[email protected]>
Cc: Lars Ellenberg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/block/drbd/drbd_int.h | 2 +-
drivers/block/drbd/drbd_main.c | 4 ++--
drivers/block/drbd/drbd_nl.c | 20 ++++++++++----------
3 files changed, 13 insertions(+), 13 deletions(-)
--- a/drivers/block/drbd/drbd_int.h
+++ b/drivers/block/drbd/drbd_int.h
@@ -75,7 +75,7 @@ extern int fault_rate;
extern int fault_devs;
#endif
-extern char usermode_helper[];
+extern char drbd_usermode_helper[];
/* This is used to stop/restart our threads.
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -109,9 +109,9 @@ int proc_details; /* Detail level
/* Module parameter for setting the user mode helper program
* to run. Default is /sbin/drbdadm */
-char usermode_helper[80] = "/sbin/drbdadm";
+char drbd_usermode_helper[80] = "/sbin/drbdadm";
-module_param_string(usermode_helper, usermode_helper, sizeof(usermode_helper), 0644);
+module_param_string(usermode_helper, drbd_usermode_helper, sizeof(drbd_usermode_helper), 0644);
/* in 2.6.x, our device mapping and config info contains our virtual gendisks
* as member "struct gendisk *vdisk;"
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -344,7 +344,7 @@ int drbd_khelper(struct drbd_device *dev
(char[60]) { }, /* address */
NULL };
char mb[14];
- char *argv[] = {usermode_helper, cmd, mb, NULL };
+ char *argv[] = {drbd_usermode_helper, cmd, mb, NULL };
struct drbd_connection *connection = first_peer_device(device)->connection;
struct sib_info sib;
int ret;
@@ -359,19 +359,19 @@ int drbd_khelper(struct drbd_device *dev
* write out any unsynced meta data changes now */
drbd_md_sync(device);
- drbd_info(device, "helper command: %s %s %s\n", usermode_helper, cmd, mb);
+ drbd_info(device, "helper command: %s %s %s\n", drbd_usermode_helper, cmd, mb);
sib.sib_reason = SIB_HELPER_PRE;
sib.helper_name = cmd;
drbd_bcast_event(device, &sib);
notify_helper(NOTIFY_CALL, device, connection, cmd, 0);
- ret = call_usermodehelper(usermode_helper, argv, envp, UMH_WAIT_PROC);
+ ret = call_usermodehelper(drbd_usermode_helper, argv, envp, UMH_WAIT_PROC);
if (ret)
drbd_warn(device, "helper command: %s %s %s exit code %u (0x%x)\n",
- usermode_helper, cmd, mb,
+ drbd_usermode_helper, cmd, mb,
(ret >> 8) & 0xff, ret);
else
drbd_info(device, "helper command: %s %s %s exit code %u (0x%x)\n",
- usermode_helper, cmd, mb,
+ drbd_usermode_helper, cmd, mb,
(ret >> 8) & 0xff, ret);
sib.sib_reason = SIB_HELPER_POST;
sib.helper_exit_code = ret;
@@ -396,24 +396,24 @@ enum drbd_peer_state conn_khelper(struct
(char[60]) { }, /* address */
NULL };
char *resource_name = connection->resource->name;
- char *argv[] = {usermode_helper, cmd, resource_name, NULL };
+ char *argv[] = {drbd_usermode_helper, cmd, resource_name, NULL };
int ret;
setup_khelper_env(connection, envp);
conn_md_sync(connection);
- drbd_info(connection, "helper command: %s %s %s\n", usermode_helper, cmd, resource_name);
+ drbd_info(connection, "helper command: %s %s %s\n", drbd_usermode_helper, cmd, resource_name);
/* TODO: conn_bcast_event() ?? */
notify_helper(NOTIFY_CALL, NULL, connection, cmd, 0);
- ret = call_usermodehelper(usermode_helper, argv, envp, UMH_WAIT_PROC);
+ ret = call_usermodehelper(drbd_usermode_helper, argv, envp, UMH_WAIT_PROC);
if (ret)
drbd_warn(connection, "helper command: %s %s %s exit code %u (0x%x)\n",
- usermode_helper, cmd, resource_name,
+ drbd_usermode_helper, cmd, resource_name,
(ret >> 8) & 0xff, ret);
else
drbd_info(connection, "helper command: %s %s %s exit code %u (0x%x)\n",
- usermode_helper, cmd, resource_name,
+ drbd_usermode_helper, cmd, resource_name,
(ret >> 8) & 0xff, ret);
/* TODO: conn_bcast_event() ?? */
notify_helper(NOTIFY_RESPONSE, NULL, connection, cmd, ret);
On Mon, Jun 05, 2017 at 11:26:23AM +0200, Greg KH wrote:
> From: Greg Kroah-Hartman <[email protected]>
>
> Nothing like having a very generic global variable in a tiny driver
> subsystem to make a mess of the global namespace...
>
> Note, there are many other "generic" named global variables in the drbd
> subsystem, someone should fix those up one day before they hit a linking
> error.
Thanks. We'll prepare a patch to that effect, probably converting some
of them to static, fixing up the rest, and submit with the updates for
the next merge window.
Lars
On Mon, Jun 05, 2017 at 11:26:23AM +0200, Greg KH wrote:
> From: Greg Kroah-Hartman <[email protected]>
>
> Nothing like having a very generic global variable in a tiny driver
> subsystem to make a mess of the global namespace...
Thanks for the patch. As this did not happen magically in mainline, I
queued it up in our out-of-tree repo.
>
> Note, there are many other "generic" named global variables in the drbd
> subsystem, someone should fix those up one day before they hit a linking
> error.
Did that as well.
Both should hit some merge-window soon.
Thanks, rck
--
Roland Kammerer
[email protected]
LINBIT | Keeping the Digital World Running
DRBD – Corosync – Pacemaker
On Thu, Jul 06, 2017 at 07:56:07PM +0200, Roland Kammerer wrote:
> On Mon, Jun 05, 2017 at 11:26:23AM +0200, Greg KH wrote:
> > From: Greg Kroah-Hartman <[email protected]>
> >
> > Nothing like having a very generic global variable in a tiny driver
> > subsystem to make a mess of the global namespace...
>
> Thanks for the patch. As this did not happen magically in mainline, I
> queued it up in our out-of-tree repo.
What does that mean, will it get sent to Linus for 4.14-rc1?
thanks,
greg k-h
On Thu, Jul 06, 2017 at 08:02:41PM +0200, Greg KH wrote:
> On Thu, Jul 06, 2017 at 07:56:07PM +0200, Roland Kammerer wrote:
> > On Mon, Jun 05, 2017 at 11:26:23AM +0200, Greg KH wrote:
> > > From: Greg Kroah-Hartman <[email protected]>
> > >
> > > Nothing like having a very generic global variable in a tiny driver
> > > subsystem to make a mess of the global namespace...
> >
> > Thanks for the patch. As this did not happen magically in mainline, I
> > queued it up in our out-of-tree repo.
>
> What does that mean, will it get sent to Linus for 4.14-rc1?
Yes.
Cheers, rck