Re: FAILED: patch "[PATCH] bcache: return 0 from bch_debug_init() if CONFIG_DEBUG_FS=n" failed to apply to 4.16-stable tree
On Sun, May 20, 2018 at 10:59:32AM +0200, Kai Krakow wrote:
Hey Greg!
The v1 version applied for me but it shows a compiler warning. I didn't try the newer version yet.
I could prepare a back-ported version.
Backported would be good.
Also, the code really is wrong even with this change. No code path should ever do anything different if debugfs is enabled or not, or based on the return value of a debugfs call. No need to check anything here at all, the function should be:
void __init bch_debug_init(void) { bcache_debug = debugfs_create_dir("bcache", NULL); }
That's it, no checking, and all is fine and good. Any result of a debugfs call can always be fed back into another debugfs call with no harm or errors happening.
thanks,
greg k-h
Hi Greg!
2018-05-20 11:04 GMT+02:00 Greg KH gregkh@linuxfoundation.org:
On Sun, May 20, 2018 at 10:59:32AM +0200, Kai Krakow wrote:
Hey Greg!
The v1 version applied for me but it shows a compiler warning. I didn't try the newer version yet.
I could prepare a back-ported version.
Backported would be good.
Currently on the way. I'm not much into kernel development so I can only apply on 4.16.9, reboot, and check if it works. Hope that's okay.
How should it be tagged then? Should I add my "Signed-off-by" or another line?
Should it be sent as a v5 version of the patch?
Also, the code really is wrong even with this change. No code path should ever do anything different if debugfs is enabled or not, or based on the return value of a debugfs call. No need to check anything here at all, the function should be:
void __init bch_debug_init(void) { bcache_debug = debugfs_create_dir("bcache", NULL); }
That's it, no checking, and all is fine and good. Any result of a debugfs call can always be fed back into another debugfs call with no harm or errors happening.
I'll try to figure out if this works, and only then send the patch.
Regards, Kai
On 2018/5/20 5:14 PM, Kai Krakow wrote:
Hi Greg!
2018-05-20 11:04 GMT+02:00 Greg KH gregkh@linuxfoundation.org:
On Sun, May 20, 2018 at 10:59:32AM +0200, Kai Krakow wrote:
Hey Greg!
The v1 version applied for me but it shows a compiler warning. I didn't try the newer version yet.
I could prepare a back-ported version.
Backported would be good.
Currently on the way. I'm not much into kernel development so I can only apply on 4.16.9, reboot, and check if it works. Hope that's okay.
How should it be tagged then? Should I add my "Signed-off-by" or another line?
Should it be sent as a v5 version of the patch?
Hi Kai,
I planed to back port the patch for stable after v4 patch merged into mainline, and good to know this patch is merged into upstream today.
So the simplest way should be back port commit 1c1a2ee1b53b ("bcache: return 0 from bch_debug_init() if CONFIG_DEBUG_FS=n") for v4.16 stable tree.
If you are working on the back port, then I will step back. Thank you for the quick response, very helpful :-)
Coly Li
Also, the code really is wrong even with this change. No code path should ever do anything different if debugfs is enabled or not, or based on the return value of a debugfs call. No need to check anything here at all, the function should be:
void __init bch_debug_init(void) { bcache_debug = debugfs_create_dir("bcache", NULL); }
That's it, no checking, and all is fine and good. Any result of a debugfs call can always be fed back into another debugfs call with no harm or errors happening.
I'll try to figure out if this works, and only then send the patch.
Regards, Kai
Hello Coly, Greg!
2018-05-20 11:38 GMT+02:00 Coly Li colyli@suse.de:
On 2018/5/20 5:14 PM, Kai Krakow wrote:
Hi Greg!
2018-05-20 11:04 GMT+02:00 Greg KH gregkh@linuxfoundation.org:
On Sun, May 20, 2018 at 10:59:32AM +0200, Kai Krakow wrote:
Hey Greg!
The v1 version applied for me but it shows a compiler warning. I didn't try the newer version yet.
I could prepare a back-ported version.
Backported would be good.
Currently on the way. I'm not much into kernel development so I can only apply on 4.16.9, reboot, and check if it works. Hope that's okay.
How should it be tagged then? Should I add my "Signed-off-by" or another line?
Should it be sent as a v5 version of the patch?
Hi Kai,
I planed to back port the patch for stable after v4 patch merged into mainline, and good to know this patch is merged into upstream today.
So the simplest way should be back port commit 1c1a2ee1b53b ("bcache: return 0 from bch_debug_init() if CONFIG_DEBUG_FS=n") for v4.16 stable tree.
I already did "git cherry-pick" as Greg suggested (with the id of the failed patch).
If you are working on the back port, then I will step back. Thank you for the quick response, very helpful :-)
Coly, then I could need your review after sending the patch.
Also, the code really is wrong even with this change. No code path should ever do anything different if debugfs is enabled or not, or based on the return value of a debugfs call. No need to check anything here at all, the function should be:
void __init bch_debug_init(void) { bcache_debug = debugfs_create_dir("bcache", NULL); }
That's it, no checking, and all is fine and good. Any result of a debugfs call can always be fed back into another debugfs call with no harm or errors happening.
I'll try to figure out if this works, and only then send the patch.
Thanks, Kai
On Sun, May 20, 2018 at 11:14:12AM +0200, Kai Krakow wrote:
Hi Greg!
2018-05-20 11:04 GMT+02:00 Greg KH gregkh@linuxfoundation.org:
On Sun, May 20, 2018 at 10:59:32AM +0200, Kai Krakow wrote:
Hey Greg!
The v1 version applied for me but it shows a compiler warning. I didn't try the newer version yet.
I could prepare a back-ported version.
Backported would be good.
Currently on the way. I'm not much into kernel development so I can only apply on 4.16.9, reboot, and check if it works. Hope that's okay.
How should it be tagged then? Should I add my "Signed-off-by" or another line?
Just like a "normal" patch, yes, signed-off-by is fine. If you do 'git cherry-pick -x -s' it will put the correct information in there.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Coly Li -
Greg KH -
Kai Krakow