On Tue, Nov 20, 2012 at 12:09:57PM +0000, Rupesh Gujare wrote: > On 20/11/12 11:40, Sachin Kamat wrote: > >kfree on NULL pointer is a no-op. > > > >Signed-off-by: Sachin Kamat <sachin.kamat@xxxxxxxxxx> > >--- > > drivers/staging/ozwpan/ozpd.c | 6 ++---- > > 1 files changed, 2 insertions(+), 4 deletions(-) > > > >diff --git a/drivers/staging/ozwpan/ozpd.c b/drivers/staging/ozwpan/ozpd.c > >index 0b3648c..118a4db 100644 > >--- a/drivers/staging/ozwpan/ozpd.c > >+++ b/drivers/staging/ozwpan/ozpd.c > >@@ -402,8 +402,7 @@ static void oz_tx_frame_free(struct oz_pd *pd, struct oz_tx_frame *f) > > f = 0; > > } > > spin_unlock_bh(&pd->tx_frame_lock); > >- if (f) > >- kfree(f); > >+ kfree(f); > > } > > /*------------------------------------------------------------------------------ > > * Context: softirq-serialized > >@@ -737,8 +736,7 @@ int oz_isoc_stream_create(struct oz_pd *pd, u8 ep_num) > > st = 0; > > } > > spin_unlock_bh(&pd->stream_lock); > >- if (st) > >- kfree(st); > >+ kfree(st); > > return 0; > > } > > /*------------------------------------------------------------------------------ > > Thanks Sachin. However I don't think I can take this patch series > for following reasons :- > > 1. Removing pointer check confuses reader about logic flow. No it doesn't, this is a normal kernel pattern. > 2. We can save few CPU cycles by checking NULL pointer here, rather > than relying on kfree(). Nope, you shouldn't have to worry about this. If this is a fast-path, then you shouldn't be using kfree() in the first place :) thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
