* debugfs_create_dir return value in acer-wmi, intel_ips and ec_sys @ 2010-11-24 23:51 Corentin Chary 2010-11-25 6:01 ` Julia Lawall 0 siblings, 1 reply; 5+ messages in thread From: Corentin Chary @ 2010-11-24 23:51 UTC (permalink / raw) To: LKML, platform-driver-x86, linux acpi, Julia Lawall Cc: Carlos Corbacho, Matthew Garrett, Axel Lin, Thomas Renninger Hi, I was checking debugfs code in platform/x86, because I want to add some files to eeepc-wmi. And I found something disturbing. The documentation says: > This call, if successful, will make a directory called name underneath the > indicated parent directory. If parent is NULL, the directory will be > created in the debugfs root. On success, the return value is a struct > dentry pointer which can be used to create files in the directory (and to > clean it up at the end). A NULL return value indicates that something went > wrong. If ERR_PTR(-ENODEV) is returned, that is an indication that the > kernel has been built without debugfs support and none of the functions > described below will work. But then, here is the code in acer-wmi: > static void remove_debugfs(void) > { > debugfs_remove(interface->debug.devices); > debugfs_remove(interface->debug.root); > } > > static int create_debugfs(void) > { > interface->debug.root = debugfs_create_dir("acer-wmi", NULL); > if (!interface->debug.root) { > printk(ACER_ERR "Failed to create debugfs directory"); > return -ENOMEM; > } this code is *not* inside #ifndef CONFIG_DEBUG_FS, so debugfs_create_dir can return ERR_PTR(-ENODEV) right ? Then, remove_debug() will call debugfs_remove(ERR_PTR(-ENODEV)) right ? So, acpi-wmi seems to have an issue when debugfs is disabled, that's "ok". But then I took a look at intel_ips : > ips->debug_root = debugfs_create_dir("ips", NULL); > if (!ips->debug_root) { > dev_err(&ips->dev->dev, > "failed to create debugfs entries: %ld\n", > PTR_ERR(ips->debug_root)); > return; > } Then PTR_ERR thing is strange, because ips->debug_root can only be NULL here... But here, it's ok to only check NULL, because it's inside #ifndef CONFIG_DEBUG_FS. So, two drivers checked, to weird error handling code. I did a quick grep and opened the first result: ec_sys.c. ec_sys.c depends on CONFIG_ACPI_EC_DEBUGFS but doesn't depend on CONFIG_DEBUG_FS. Here, again, the code only check for != NULL while it could be ERR_PTR(- ENODEV): > if (ec_device_count == 0) { > acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL); > if (!acpi_ec_debugfs_dir) > return -ENOMEM; > } > > sprintf(name, "ec%u", ec_device_count); > dev_dir = debugfs_create_dir(name, acpi_ec_debugfs_dir); Here, acpi_ec_debugfs_dir (that can be an invalid pointer) is used as a parent dentry, and will be dereferenced without checks. I am missing something obvious, or are most of debugfs implementation broken when debugfs is disabled ? Julia, if I am right, coccinelle could help us right ? Can the tool check if the code is between #ifdef CONFIG_DEBUGS_FS ? That would help a lot. Thanks, -- Corentin Chary http://xf.iksaif.net ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: debugfs_create_dir return value in acer-wmi, intel_ips and ec_sys 2010-11-24 23:51 debugfs_create_dir return value in acer-wmi, intel_ips and ec_sys Corentin Chary @ 2010-11-25 6:01 ` Julia Lawall 2010-11-25 6:40 ` Corentin Chary 0 siblings, 1 reply; 5+ messages in thread From: Julia Lawall @ 2010-11-25 6:01 UTC (permalink / raw) To: Corentin Chary Cc: LKML, platform-driver-x86, linux acpi, Carlos Corbacho, Matthew Garrett, Axel Lin, Thomas Renninger On Thu, 25 Nov 2010, Corentin Chary wrote: > Hi, > > I was checking debugfs code in platform/x86, because I want to add > some files to eeepc-wmi. And I found something disturbing. > > The documentation says: > > > This call, if successful, will make a directory called name underneath the > > indicated parent directory. If parent is NULL, the directory will be > > created in the debugfs root. On success, the return value is a struct > > dentry pointer which can be used to create files in the directory (and to > > clean it up at the end). A NULL return value indicates that something went > > wrong. If ERR_PTR(-ENODEV) is returned, that is an indication that the > > kernel has been built without debugfs support and none of the functions > > described below will work. > > But then, here is the code in acer-wmi: > > > static void remove_debugfs(void) > > { > > debugfs_remove(interface->debug.devices); > > debugfs_remove(interface->debug.root); > > } > > > > static int create_debugfs(void) > > { > > interface->debug.root = debugfs_create_dir("acer-wmi", NULL); > > if (!interface->debug.root) { > > printk(ACER_ERR "Failed to create debugfs directory"); > > return -ENOMEM; > > } > > this code is *not* inside #ifndef CONFIG_DEBUG_FS, so debugfs_create_dir > can return ERR_PTR(-ENODEV) right ? > > Then, remove_debug() will call debugfs_remove(ERR_PTR(-ENODEV)) right ? > > So, acpi-wmi seems to have an issue when debugfs is disabled, that's "ok". > > But then I took a look at intel_ips : > > > ips->debug_root = debugfs_create_dir("ips", NULL); > > if (!ips->debug_root) { > > dev_err(&ips->dev->dev, > > "failed to create debugfs entries: %ld\n", > > PTR_ERR(ips->debug_root)); > > return; > > } > > Then PTR_ERR thing is strange, because ips->debug_root can only be NULL > here... > But here, it's ok to only check NULL, because it's inside #ifndef > CONFIG_DEBUG_FS. > > So, two drivers checked, to weird error handling code. I did a quick grep and > opened > the first result: ec_sys.c. > > ec_sys.c depends on CONFIG_ACPI_EC_DEBUGFS but doesn't depend on > CONFIG_DEBUG_FS. > > Here, again, the code only check for != NULL while it could be ERR_PTR(- > ENODEV): > > > if (ec_device_count == 0) { > > acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL); > > if (!acpi_ec_debugfs_dir) > > return -ENOMEM; > > } > > > > sprintf(name, "ec%u", ec_device_count); > > dev_dir = debugfs_create_dir(name, acpi_ec_debugfs_dir); > > Here, acpi_ec_debugfs_dir (that can be an invalid pointer) is used as > a parent dentry, and will be dereferenced without checks. > > I am missing something obvious, or are most of debugfs implementation > broken when debugfs is disabled ? > > Julia, if I am right, coccinelle could help us right ? Can the tool check > if the code is between #ifdef CONFIG_DEBUGS_FS ? That would help a lot. Unfortunately, at the moment, it can't; there is no matching on #ifdefs. Perhaps it could be added. I wonder though if sometimes returning NULL and sometimes returning ERR_PTR is something that should be encouraged? Would one rather convert the NULL case to a specific ERR_PTR case? julia ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: debugfs_create_dir return value in acer-wmi, intel_ips and ec_sys 2010-11-25 6:01 ` Julia Lawall @ 2010-11-25 6:40 ` Corentin Chary 2010-11-25 10:21 ` Julia Lawall 0 siblings, 1 reply; 5+ messages in thread From: Corentin Chary @ 2010-11-25 6:40 UTC (permalink / raw) To: Julia Lawall Cc: LKML, platform-driver-x86, linux acpi, Carlos Corbacho, Matthew Garrett, Axel Lin, Thomas Renninger On Thu, Nov 25, 2010 at 7:01 AM, Julia Lawall <julia@diku.dk> wrote: > On Thu, 25 Nov 2010, Corentin Chary wrote: > >> Hi, >> >> I was checking debugfs code in platform/x86, because I want to add >> some files to eeepc-wmi. And I found something disturbing. >> >> The documentation says: >> >> > This call, if successful, will make a directory called name underneath the >> > indicated parent directory. If parent is NULL, the directory will be >> > created in the debugfs root. On success, the return value is a struct >> > dentry pointer which can be used to create files in the directory (and to >> > clean it up at the end). A NULL return value indicates that something went >> > wrong. If ERR_PTR(-ENODEV) is returned, that is an indication that the >> > kernel has been built without debugfs support and none of the functions >> > described below will work. >> >> But then, here is the code in acer-wmi: >> >> > static void remove_debugfs(void) >> > { >> > debugfs_remove(interface->debug.devices); >> > debugfs_remove(interface->debug.root); >> > } >> > >> > static int create_debugfs(void) >> > { >> > interface->debug.root = debugfs_create_dir("acer-wmi", NULL); >> > if (!interface->debug.root) { >> > printk(ACER_ERR "Failed to create debugfs directory"); >> > return -ENOMEM; >> > } >> >> this code is *not* inside #ifndef CONFIG_DEBUG_FS, so debugfs_create_dir >> can return ERR_PTR(-ENODEV) right ? >> >> Then, remove_debug() will call debugfs_remove(ERR_PTR(-ENODEV)) right ? >> >> So, acpi-wmi seems to have an issue when debugfs is disabled, that's "ok". >> >> But then I took a look at intel_ips : >> >> > ips->debug_root = debugfs_create_dir("ips", NULL); >> > if (!ips->debug_root) { >> > dev_err(&ips->dev->dev, >> > "failed to create debugfs entries: %ld\n", >> > PTR_ERR(ips->debug_root)); >> > return; >> > } >> >> Then PTR_ERR thing is strange, because ips->debug_root can only be NULL >> here... >> But here, it's ok to only check NULL, because it's inside #ifndef >> CONFIG_DEBUG_FS. >> >> So, two drivers checked, to weird error handling code. I did a quick grep and >> opened >> the first result: ec_sys.c. >> >> ec_sys.c depends on CONFIG_ACPI_EC_DEBUGFS but doesn't depend on >> CONFIG_DEBUG_FS. >> >> Here, again, the code only check for != NULL while it could be ERR_PTR(- >> ENODEV): >> >> > if (ec_device_count == 0) { >> > acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL); >> > if (!acpi_ec_debugfs_dir) >> > return -ENOMEM; >> > } >> > >> > sprintf(name, "ec%u", ec_device_count); >> > dev_dir = debugfs_create_dir(name, acpi_ec_debugfs_dir); >> >> Here, acpi_ec_debugfs_dir (that can be an invalid pointer) is used as >> a parent dentry, and will be dereferenced without checks. >> >> I am missing something obvious, or are most of debugfs implementation >> broken when debugfs is disabled ? Answer to myself, when debugfs is disabled, it's ok to give broken dentry pointers to debugfs functions since they won't do anything. >> Julia, if I am right, coccinelle could help us right ? Can the tool check >> if the code is between #ifdef CONFIG_DEBUGS_FS ? That would help a lot. > > Unfortunately, at the moment, it can't; there is no matching on #ifdefs. > Perhaps it could be added. Or better, something to check if a macro is defined in a particular contact ? > I wonder though if sometimes returning NULL and sometimes returning > ERR_PTR is something that should be encouraged? Would one rather convert > the NULL case to a specific ERR_PTR case? But yeah, I found debugfs API disturbing, but it seems to be done like that to ease the "debugfs is disabled case". Thanks, -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: debugfs_create_dir return value in acer-wmi, intel_ips and ec_sys 2010-11-25 6:40 ` Corentin Chary @ 2010-11-25 10:21 ` Julia Lawall 2010-11-26 16:53 ` Reinhard Tartler 0 siblings, 1 reply; 5+ messages in thread From: Julia Lawall @ 2010-11-25 10:21 UTC (permalink / raw) To: Corentin Chary Cc: LKML, platform-driver-x86, linux acpi, Carlos Corbacho, Matthew Garrett, Axel Lin, Thomas Renninger, daniel.lohmann, Reinhard.Tartler, Julio.Sincero [-- Attachment #1: Type: TEXT/PLAIN, Size: 4329 bytes --] On Thu, 25 Nov 2010, Corentin Chary wrote: > On Thu, Nov 25, 2010 at 7:01 AM, Julia Lawall <julia@diku.dk> wrote: > > On Thu, 25 Nov 2010, Corentin Chary wrote: > > > >> Hi, > >> > >> I was checking debugfs code in platform/x86, because I want to add > >> some files to eeepc-wmi. And I found something disturbing. > >> > >> The documentation says: > >> > >> > This call, if successful, will make a directory called name underneath the > >> > indicated parent directory. If parent is NULL, the directory will be > >> > created in the debugfs root. On success, the return value is a struct > >> > dentry pointer which can be used to create files in the directory (and to > >> > clean it up at the end). A NULL return value indicates that something went > >> > wrong. If ERR_PTR(-ENODEV) is returned, that is an indication that the > >> > kernel has been built without debugfs support and none of the functions > >> > described below will work. > >> > >> But then, here is the code in acer-wmi: > >> > >> > static void remove_debugfs(void) > >> > { > >> > debugfs_remove(interface->debug.devices); > >> > debugfs_remove(interface->debug.root); > >> > } > >> > > >> > static int create_debugfs(void) > >> > { > >> > interface->debug.root = debugfs_create_dir("acer-wmi", NULL); > >> > if (!interface->debug.root) { > >> > printk(ACER_ERR "Failed to create debugfs directory"); > >> > return -ENOMEM; > >> > } > >> > >> this code is *not* inside #ifndef CONFIG_DEBUG_FS, so debugfs_create_dir > >> can return ERR_PTR(-ENODEV) right ? > >> > >> Then, remove_debug() will call debugfs_remove(ERR_PTR(-ENODEV)) right ? > >> > >> So, acpi-wmi seems to have an issue when debugfs is disabled, that's "ok". > >> > >> But then I took a look at intel_ips : > >> > >> > ips->debug_root = debugfs_create_dir("ips", NULL); > >> > if (!ips->debug_root) { > >> > dev_err(&ips->dev->dev, > >> > "failed to create debugfs entries: %ld\n", > >> > PTR_ERR(ips->debug_root)); > >> > return; > >> > } > >> > >> Then PTR_ERR thing is strange, because ips->debug_root can only be NULL > >> here... > >> But here, it's ok to only check NULL, because it's inside #ifndef > >> CONFIG_DEBUG_FS. > >> > >> So, two drivers checked, to weird error handling code. I did a quick grep and > >> opened > >> the first result: ec_sys.c. > >> > >> ec_sys.c depends on CONFIG_ACPI_EC_DEBUGFS but doesn't depend on > >> CONFIG_DEBUG_FS. > >> > >> Here, again, the code only check for != NULL while it could be ERR_PTR(- > >> ENODEV): > >> > >> > if (ec_device_count == 0) { > >> > acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL); > >> > if (!acpi_ec_debugfs_dir) > >> > return -ENOMEM; > >> > } > >> > > >> > sprintf(name, "ec%u", ec_device_count); > >> > dev_dir = debugfs_create_dir(name, acpi_ec_debugfs_dir); > >> > >> Here, acpi_ec_debugfs_dir (that can be an invalid pointer) is used as > >> a parent dentry, and will be dereferenced without checks. > >> > >> I am missing something obvious, or are most of debugfs implementation > >> broken when debugfs is disabled ? > > Answer to myself, when debugfs is disabled, it's ok to give broken > dentry pointers to debugfs functions since they won't do anything. > > >> Julia, if I am right, coccinelle could help us right ? Can the tool check > >> if the code is between #ifdef CONFIG_DEBUGS_FS ? That would help a lot. > > > > Unfortunately, at the moment, it can't; there is no matching on #ifdefs. > > Perhaps it could be added. > > Or better, something to check if a macro is defined in a particular contact ? Actually, Daniel Lohmann's group has been working on analyzing #ifdef's. Perhaps they have a solution to this problem? I have added them to the CC list. julia > > I wonder though if sometimes returning NULL and sometimes returning > > ERR_PTR is something that should be encouraged? Would one rather convert > > the NULL case to a specific ERR_PTR case? > > But yeah, I found debugfs API disturbing, but it seems to be done like that to > ease the "debugfs is disabled case". > > Thanks, > -- > Corentin Chary > http://xf.iksaif.net > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: debugfs_create_dir return value in acer-wmi, intel_ips and ec_sys 2010-11-25 10:21 ` Julia Lawall @ 2010-11-26 16:53 ` Reinhard Tartler 0 siblings, 0 replies; 5+ messages in thread From: Reinhard Tartler @ 2010-11-26 16:53 UTC (permalink / raw) To: Corentin Chary, LKML, platform-driver-x86, linux acpi, Carlos Corbacho <carlos@ Cc: Julia Lawall On Thu, Nov 25, 2010 at 11:21:20 (CET), Julia Lawall wrote: > On Thu, 25 Nov 2010, Corentin Chary wrote: > >> On Thu, Nov 25, 2010 at 7:01 AM, Julia Lawall <julia@diku.dk> wrote: >> > On Thu, 25 Nov 2010, Corentin Chary wrote: >> > >> >> Hi, >> >> >> >> I was checking debugfs code in platform/x86, because I want to add >> >> some files to eeepc-wmi. And I found something disturbing. >> >> >> >> The documentation says: >> >> >> >> > This call, if successful, will make a directory called name underneath the >> >> > indicated parent directory. If parent is NULL, the directory will be >> >> > created in the debugfs root. On success, the return value is a struct >> >> > dentry pointer which can be used to create files in the directory (and to >> >> > clean it up at the end). A NULL return value indicates that something went >> >> > wrong. If ERR_PTR(-ENODEV) is returned, that is an indication that the >> >> > kernel has been built without debugfs support and none of the functions >> >> > described below will work. >> >> >> >> But then, here is the code in acer-wmi: >> >> >> >> > static void remove_debugfs(void) >> >> > { >> >> > debugfs_remove(interface->debug.devices); >> >> > debugfs_remove(interface->debug.root); >> >> > } >> >> > >> >> > static int create_debugfs(void) >> >> > { >> >> > interface->debug.root = debugfs_create_dir("acer-wmi", NULL); >> >> > if (!interface->debug.root) { >> >> > printk(ACER_ERR "Failed to create debugfs directory"); >> >> > return -ENOMEM; >> >> > } >> >> >> >> this code is *not* inside #ifndef CONFIG_DEBUG_FS, so debugfs_create_dir >> >> can return ERR_PTR(-ENODEV) right ? >> >> >> >> Then, remove_debug() will call debugfs_remove(ERR_PTR(-ENODEV)) right ? >> >> >> >> So, acpi-wmi seems to have an issue when debugfs is disabled, that's "ok". >> >> >> >> But then I took a look at intel_ips : >> >> >> >> > ips->debug_root = debugfs_create_dir("ips", NULL); >> >> > if (!ips->debug_root) { >> >> > dev_err(&ips->dev->dev, >> >> > "failed to create debugfs entries: %ld\n", >> >> > PTR_ERR(ips->debug_root)); >> >> > return; >> >> > } >> >> >> >> Then PTR_ERR thing is strange, because ips->debug_root can only be NULL >> >> here... >> >> But here, it's ok to only check NULL, because it's inside #ifndef >> >> CONFIG_DEBUG_FS. >> >> >> >> So, two drivers checked, to weird error handling code. I did a quick grep and >> >> opened >> >> the first result: ec_sys.c. >> >> >> >> ec_sys.c depends on CONFIG_ACPI_EC_DEBUGFS but doesn't depend on >> >> CONFIG_DEBUG_FS. >> >> >> >> Here, again, the code only check for != NULL while it could be ERR_PTR(- >> >> ENODEV): >> >> >> >> > if (ec_device_count == 0) { >> >> > acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL); >> >> > if (!acpi_ec_debugfs_dir) >> >> > return -ENOMEM; >> >> > } >> >> > >> >> > sprintf(name, "ec%u", ec_device_count); >> >> > dev_dir = debugfs_create_dir(name, acpi_ec_debugfs_dir); >> >> >> >> Here, acpi_ec_debugfs_dir (that can be an invalid pointer) is used as >> >> a parent dentry, and will be dereferenced without checks. >> >> >> >> I am missing something obvious, or are most of debugfs implementation >> >> broken when debugfs is disabled ? >> >> Answer to myself, when debugfs is disabled, it's ok to give broken >> dentry pointers to debugfs functions since they won't do anything. >> >> >> Julia, if I am right, coccinelle could help us right ? Can the tool check >> >> if the code is between #ifdef CONFIG_DEBUGS_FS ? That would help a lot. >> > >> > Unfortunately, at the moment, it can't; there is no matching on #ifdefs. >> > Perhaps it could be added. >> >> Or better, something to check if a macro is defined in a particular contact ? > > Actually, Daniel Lohmann's group has been working on analyzing #ifdef's. > Perhaps they have a solution to this problem? I have added them to the CC > list. Thanks for bringing this thread to our attention, Julia. We indeed do have a tool that is able to calculate the conditions under which a line of code is activated or not, taking the constraints from Kconfig into account. This allows us e.g. to find nested/broken ifdefs like #ifndef CONFIG_DEBUG_FS ... #ifdef CONFIG_DEBUG_FS #else #endif ... #endif because we are taking kconfig into account, the inner CPP item can also be some other kconfig item on which CONFIG_DEBUG_FS depends and we would still find it. I'm not sure yet how to turn this technique into a tool that would be helpful to solve this particular problem. Maybe we can integrate this somehow in coccinelle? regards, Reinhard. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-11-26 17:24 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-24 23:51 debugfs_create_dir return value in acer-wmi, intel_ips and ec_sys Corentin Chary 2010-11-25 6:01 ` Julia Lawall 2010-11-25 6:40 ` Corentin Chary 2010-11-25 10:21 ` Julia Lawall 2010-11-26 16:53 ` Reinhard Tartler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox