On Sat, 15 Aug 2015 13:26:36 +0600 Alexander Kuleshov <kuleshovmail@xxxxxxxxx> wrote: > Hello Andrew, > > On 08-14-15, Andrew Morton wrote: > > On Sat, 15 Aug 2015 01:03:31 +0600 Alexander Kuleshov <kuleshovmail@xxxxxxxxx> wrote: > > > > > Signed-off-by: Alexander Kuleshov <kuleshovmail@xxxxxxxxx> > > > > There's no changelog. > > Yes, will add it if there will be sense in the patch. > > > > > Why? Ignoring the debugfs API return values is standard practice. > > > > Yes, but I saw many places where this practice is applicable (for example > in the kernel/kprobes and etc.), besides this, the memblock API is used > mostly at early stage, so we will have some output if something going wrong. The debugfs error-handling rules are something Greg cooked up after one too many beers. I've never understood them, but maybe I continue to miss the point. Yes, I agree that if memblock's debugfs_create_file() fails, we want to know about it because something needs fixing. But that's true of all(?) debugfs_create_file callsites, so it's a bit silly to add warnings to them all. Why not put the warning into debugfs_create_file() itself? And add a debugfs_create_file_no_warn() if there are callsites which have reason to go it alone. Or add a debugfs_create_file_warn() wrapper. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>