* [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails
@ 2016-10-12 8:14 Dan Carpenter
2016-10-12 8:30 ` Johannes Thumshirn
0 siblings, 1 reply; 10+ messages in thread
From: Dan Carpenter @ 2016-10-12 8:14 UTC (permalink / raw)
To: jthumshirn; +Cc: linux-gpio
Hello Johannes Thumshirn,
The patch e1547af8c059: "pinctrl: berlin: Don't leak memory if
krealloc() fails" from Sep 30, 2016, leads to the following static
checker warning:
drivers/pinctrl/berlin/berlin.c:244 berlin_pinctrl_build_state()
warn: passing devm_ allocated variable to kfree. 'pctrl->functions'
drivers/pinctrl/berlin/berlin.c
221
222 /* we will reallocate later */
223 pctrl->functions = devm_kzalloc(&pdev->dev,
224 max_functions * sizeof(*pctrl->functions),
225 GFP_KERNEL);
226 if (!pctrl->functions)
227 return -ENOMEM;
228
229 /* register all functions */
230 for (i = 0; i < pctrl->desc->ngroups; i++) {
231 desc_group = pctrl->desc->groups + i;
232 desc_function = desc_group->functions;
233
234 while (desc_function->name) {
235 berlin_pinctrl_add_function(pctrl, desc_function->name);
236 desc_function++;
237 }
238 }
239
240 functions = krealloc(pctrl->functions,
241 pctrl->nfunctions * sizeof(*pctrl->functions),
242 GFP_KERNEL);
243 if (!functions) {
244 kfree(pctrl->functions);
This will lead to a double free.
245 return -ENOMEM;
246 }
247 pctrl->functions = functions;
I'm really concerned about this generally. It's like we can't tell if
pctrl->functions is a managed allocation or not, and I can't immediately
see where it is freed when it's unmanaged.
248
regards,
dan carpenter
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails 2016-10-12 8:14 [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails Dan Carpenter @ 2016-10-12 8:30 ` Johannes Thumshirn 2016-10-12 8:45 ` Dan Carpenter 0 siblings, 1 reply; 10+ messages in thread From: Johannes Thumshirn @ 2016-10-12 8:30 UTC (permalink / raw) To: Dan Carpenter; +Cc: linux-gpio On Wed, Oct 12, 2016 at 11:14:22AM +0300, Dan Carpenter wrote: > Hello Johannes Thumshirn, > > The patch e1547af8c059: "pinctrl: berlin: Don't leak memory if > krealloc() fails" from Sep 30, 2016, leads to the following static > checker warning: > > drivers/pinctrl/berlin/berlin.c:244 berlin_pinctrl_build_state() > warn: passing devm_ allocated variable to kfree. 'pctrl->functions' > > drivers/pinctrl/berlin/berlin.c > 221 > 222 /* we will reallocate later */ > 223 pctrl->functions = devm_kzalloc(&pdev->dev, > 224 max_functions * sizeof(*pctrl->functions), > 225 GFP_KERNEL); > 226 if (!pctrl->functions) > 227 return -ENOMEM; > 228 > 229 /* register all functions */ > 230 for (i = 0; i < pctrl->desc->ngroups; i++) { > 231 desc_group = pctrl->desc->groups + i; > 232 desc_function = desc_group->functions; > 233 > 234 while (desc_function->name) { > 235 berlin_pinctrl_add_function(pctrl, desc_function->name); > 236 desc_function++; > 237 } > 238 } > 239 > 240 functions = krealloc(pctrl->functions, > 241 pctrl->nfunctions * sizeof(*pctrl->functions), > 242 GFP_KERNEL); > 243 if (!functions) { > 244 kfree(pctrl->functions); > > This will lead to a double free. > > 245 return -ENOMEM; > 246 } > 247 pctrl->functions = functions; > > I'm really concerned about this generally. It's like we can't tell if > pctrl->functions is a managed allocation or not, and I can't immediately > see where it is freed when it's unmanaged. > > 248 > > regards, > dan carpenter Oh I see. Damn, missed the devm_kzalloc(). But shouldn't we avoid krealloc() on devm_kzalloc() in general? krealloc() calls kfree() if the reallocation succeeded and this will break the devres tracking, wouldn't it? Byte, Johannes -- Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails 2016-10-12 8:30 ` Johannes Thumshirn @ 2016-10-12 8:45 ` Dan Carpenter 2016-10-12 9:44 ` Johannes Thumshirn 0 siblings, 1 reply; 10+ messages in thread From: Dan Carpenter @ 2016-10-12 8:45 UTC (permalink / raw) To: Johannes Thumshirn; +Cc: linux-gpio On Wed, Oct 12, 2016 at 10:30:02AM +0200, Johannes Thumshirn wrote: > Oh I see. Damn, missed the devm_kzalloc(). But shouldn't we avoid krealloc() > on devm_kzalloc() in general? krealloc() calls kfree() if the reallocation > succeeded and this will break the devres tracking, wouldn't it? Good point. I will update my test to check for that. regards, dan carpenter ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails 2016-10-12 8:45 ` Dan Carpenter @ 2016-10-12 9:44 ` Johannes Thumshirn 2016-10-12 11:19 ` Dan Carpenter 0 siblings, 1 reply; 10+ messages in thread From: Johannes Thumshirn @ 2016-10-12 9:44 UTC (permalink / raw) To: Dan Carpenter, Linus Walleij; +Cc: linux-gpio On Wed, Oct 12, 2016 at 11:45:27AM +0300, Dan Carpenter wrote: > On Wed, Oct 12, 2016 at 10:30:02AM +0200, Johannes Thumshirn wrote: > > Oh I see. Damn, missed the devm_kzalloc(). But shouldn't we avoid krealloc() > > on devm_kzalloc() in general? krealloc() calls kfree() if the reallocation > > succeeded and this will break the devres tracking, wouldn't it? > > Good point. I will update my test to check for that. Well the initial problem still stands, how do we fix the possible double free? I think I could "just" change the devm_kzalloc() to kzalloc() (and introduce cleanups) but I'm not sure this is a good solution. The whoule point of these devm stuff is to apply a safety net, isn't it? Linus how shall we proceed? Reverting the patch keeps the double-free (IMHO but I'm not 100% sure how this devres tracking works if we do a realloc on the pointer) and reintroduces the memory leak. Byte, Johannes -- Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails 2016-10-12 9:44 ` Johannes Thumshirn @ 2016-10-12 11:19 ` Dan Carpenter 2016-10-12 12:36 ` Johannes Thumshirn 0 siblings, 1 reply; 10+ messages in thread From: Dan Carpenter @ 2016-10-12 11:19 UTC (permalink / raw) To: Johannes Thumshirn; +Cc: Linus Walleij, linux-gpio On Wed, Oct 12, 2016 at 11:44:36AM +0200, Johannes Thumshirn wrote: > On Wed, Oct 12, 2016 at 11:45:27AM +0300, Dan Carpenter wrote: > > On Wed, Oct 12, 2016 at 10:30:02AM +0200, Johannes Thumshirn wrote: > > > Oh I see. Damn, missed the devm_kzalloc(). But shouldn't we avoid krealloc() > > > on devm_kzalloc() in general? krealloc() calls kfree() if the reallocation > > > succeeded and this will break the devres tracking, wouldn't it? > > > > Good point. I will update my test to check for that. > > Well the initial problem still stands, how do we fix the possible double > free? I think I could "just" change the devm_kzalloc() to kzalloc() (and > introduce cleanups) but I'm not sure this is a good solution. The whoule point > of these devm stuff is to apply a safety net, isn't it? No. It's just a convenience because we allocate so much stuff on probe. A few people use it like that, where they try to manage their own memory and use devm_ at the same time and it annoys me. Just use kzalloc(). But make sure there is a free somewhere. regards, dan carpenter ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails 2016-10-12 11:19 ` Dan Carpenter @ 2016-10-12 12:36 ` Johannes Thumshirn 2016-10-12 17:06 ` Dan Carpenter 0 siblings, 1 reply; 10+ messages in thread From: Johannes Thumshirn @ 2016-10-12 12:36 UTC (permalink / raw) To: Dan Carpenter; +Cc: Linus Walleij, linux-gpio On Wed, Oct 12, 2016 at 02:19:24PM +0300, Dan Carpenter wrote: > On Wed, Oct 12, 2016 at 11:44:36AM +0200, Johannes Thumshirn wrote: > > On Wed, Oct 12, 2016 at 11:45:27AM +0300, Dan Carpenter wrote: > > > On Wed, Oct 12, 2016 at 10:30:02AM +0200, Johannes Thumshirn wrote: > > > > Oh I see. Damn, missed the devm_kzalloc(). But shouldn't we avoid krealloc() > > > > on devm_kzalloc() in general? krealloc() calls kfree() if the reallocation > > > > succeeded and this will break the devres tracking, wouldn't it? > > > > > > Good point. I will update my test to check for that. > > > > Well the initial problem still stands, how do we fix the possible double > > free? I think I could "just" change the devm_kzalloc() to kzalloc() (and > > introduce cleanups) but I'm not sure this is a good solution. The whoule point > > of these devm stuff is to apply a safety net, isn't it? > > No. It's just a convenience because we allocate so much stuff on probe. > A few people use it like that, where they try to manage their own memory > and use devm_ at the same time and it annoys me. > > Just use kzalloc(). But make sure there is a free somewhere. Unfortunately changing the allocation function for pctrl->functions in berlin_pinctrl_build_state() also ment that I had to change it for the function group so the error handling path is not so straight forward. That's what I came up with: >From 41899a7bce490a49b5cebe9586a07ff7e2f1b784 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn@suse.de> Date: Wed, 12 Oct 2016 14:15:52 +0200 Subject: [PATCH] pinctrl: berlin: don't krealloc devm managed memory Don't krealloc devm managed memory instead allocate the memory which will likely get reallocated using the traditional unmanaged allocators. Fixes: e1547af8c (pinctrl: berlin: Don't leak memory if krealloc() fails) Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> --- drivers/pinctrl/berlin/berlin-bg2.c | 1 + drivers/pinctrl/berlin/berlin-bg2cd.c | 1 + drivers/pinctrl/berlin/berlin-bg2q.c | 1 + drivers/pinctrl/berlin/berlin-bg4ct.c | 1 + drivers/pinctrl/berlin/berlin.c | 60 ++++++++++++++++++++++++----------- drivers/pinctrl/berlin/berlin.h | 21 ++++++++++++ 6 files changed, 66 insertions(+), 19 deletions(-) diff --git a/drivers/pinctrl/berlin/berlin-bg2.c b/drivers/pinctrl/berlin/berlin-bg2.c index fabe728..733bc62 100644 --- a/drivers/pinctrl/berlin/berlin-bg2.c +++ b/drivers/pinctrl/berlin/berlin-bg2.c @@ -239,6 +239,7 @@ static int berlin2_pinctrl_probe(struct platform_device *pdev) static struct platform_driver berlin2_pinctrl_driver = { .probe = berlin2_pinctrl_probe, + .remove = berlin_pinctrl_remove, .driver = { .name = "berlin-bg2-pinctrl", .of_match_table = berlin2_pinctrl_match, diff --git a/drivers/pinctrl/berlin/berlin-bg2cd.c b/drivers/pinctrl/berlin/berlin-bg2cd.c index ad8c758..70fcc77 100644 --- a/drivers/pinctrl/berlin/berlin-bg2cd.c +++ b/drivers/pinctrl/berlin/berlin-bg2cd.c @@ -184,6 +184,7 @@ static int berlin2cd_pinctrl_probe(struct platform_device *pdev) static struct platform_driver berlin2cd_pinctrl_driver = { .probe = berlin2cd_pinctrl_probe, + .remove = berlin_pinctrl_remove, .driver = { .name = "berlin-bg2cd-pinctrl", .of_match_table = berlin2cd_pinctrl_match, diff --git a/drivers/pinctrl/berlin/berlin-bg2q.c b/drivers/pinctrl/berlin/berlin-bg2q.c index cd171ae..a0e80f4 100644 --- a/drivers/pinctrl/berlin/berlin-bg2q.c +++ b/drivers/pinctrl/berlin/berlin-bg2q.c @@ -401,6 +401,7 @@ static int berlin2q_pinctrl_probe(struct platform_device *pdev) static struct platform_driver berlin2q_pinctrl_driver = { .probe = berlin2q_pinctrl_probe, + .remove = berlin_pinctrl_remove, .driver = { .name = "berlin-bg2q-pinctrl", .of_match_table = berlin2q_pinctrl_match, diff --git a/drivers/pinctrl/berlin/berlin-bg4ct.c b/drivers/pinctrl/berlin/berlin-bg4ct.c index 0917204..f91eaae 100644 --- a/drivers/pinctrl/berlin/berlin-bg4ct.c +++ b/drivers/pinctrl/berlin/berlin-bg4ct.c @@ -491,6 +491,7 @@ static int berlin4ct_pinctrl_probe(struct platform_device *pdev) static struct platform_driver berlin4ct_pinctrl_driver = { .probe = berlin4ct_pinctrl_probe, + .remove = berlin_pinctrl_remove, .driver = { .name = "berlin4ct-pinctrl", .of_match_table = berlin4ct_pinctrl_match, diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c index 76281c8..0774973 100644 --- a/drivers/pinctrl/berlin/berlin.c +++ b/drivers/pinctrl/berlin/berlin.c @@ -26,15 +26,6 @@ #include "../pinctrl-utils.h" #include "berlin.h" -struct berlin_pinctrl { - struct regmap *regmap; - struct device *dev; - const struct berlin_pinctrl_desc *desc; - struct berlin_pinctrl_function *functions; - unsigned nfunctions; - struct pinctrl_dev *pctrl_dev; -}; - static int berlin_pinctrl_get_group_count(struct pinctrl_dev *pctrl_dev) { struct berlin_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrl_dev); @@ -203,6 +194,26 @@ static int berlin_pinctrl_add_function(struct berlin_pinctrl *pctrl, return 0; } +void berlin_pinctrl_free_funcgroups(struct berlin_pinctrl *pctrl) +{ + struct berlin_desc_group const *desc_group; + struct berlin_desc_function const *desc_function; + int i; + + for (i = 0; i < pctrl->desc->ngroups; i++) { + desc_group = pctrl->desc->groups + i; + desc_function = desc_group->functions; + + while (desc_function->name) { + struct berlin_pinctrl_function + *function = pctrl->functions; + + kfree(function->groups); + desc_function++; + } + } +} + static int berlin_pinctrl_build_state(struct platform_device *pdev) { struct berlin_pinctrl *pctrl = platform_get_drvdata(pdev); @@ -210,6 +221,7 @@ static int berlin_pinctrl_build_state(struct platform_device *pdev) struct berlin_desc_function const *desc_function; struct berlin_pinctrl_function *functions; int i, max_functions = 0; + int ret; pctrl->nfunctions = 0; @@ -220,9 +232,8 @@ static int berlin_pinctrl_build_state(struct platform_device *pdev) } /* we will reallocate later */ - pctrl->functions = devm_kzalloc(&pdev->dev, - max_functions * sizeof(*pctrl->functions), - GFP_KERNEL); + pctrl->functions = kcalloc(max_functions, sizeof(*pctrl->functions), + GFP_KERNEL); if (!pctrl->functions) return -ENOMEM; @@ -265,17 +276,21 @@ static int berlin_pinctrl_build_state(struct platform_device *pdev) function++; } - if (!found) - return -EINVAL; + if (!found) { + ret = -EINVAL; + goto free_functions; + } if (!function->groups) { function->groups = - devm_kzalloc(&pdev->dev, - function->ngroups * sizeof(char *), - GFP_KERNEL); + kcalloc(function->ngroups, + sizeof(char *), + GFP_KERNEL); - if (!function->groups) - return -ENOMEM; + if (!function->groups) { + ret = -ENOMEM; + goto free_functions; + } } groups = function->groups; @@ -289,6 +304,11 @@ static int berlin_pinctrl_build_state(struct platform_device *pdev) } return 0; + +free_functions: + berlin_pinctrl_free_funcgroups(pctrl); + kfree(pctrl->functions); + return ret; } static struct pinctrl_desc berlin_pctrl_desc = { @@ -326,6 +346,8 @@ int berlin_pinctrl_probe_regmap(struct platform_device *pdev, pctrl); if (IS_ERR(pctrl->pctrl_dev)) { dev_err(dev, "failed to register pinctrl driver\n"); + berlin_pinctrl_free_funcgroups(pctrl); + kfree(pctrl->functions); return PTR_ERR(pctrl->pctrl_dev); } diff --git a/drivers/pinctrl/berlin/berlin.h b/drivers/pinctrl/berlin/berlin.h index e9b30f9..a50686c 100644 --- a/drivers/pinctrl/berlin/berlin.h +++ b/drivers/pinctrl/berlin/berlin.h @@ -13,6 +13,17 @@ #ifndef __PINCTRL_BERLIN_H #define __PINCTRL_BERLIN_H +#include <linux/slab.h> + +struct berlin_pinctrl { + struct regmap *regmap; + struct device *dev; + const struct berlin_pinctrl_desc *desc; + struct berlin_pinctrl_function *functions; + unsigned nfunctions; + struct pinctrl_dev *pctrl_dev; +}; + struct berlin_desc_function { const char *name; u8 muxval; @@ -61,5 +72,15 @@ int berlin_pinctrl_probe(struct platform_device *pdev, int berlin_pinctrl_probe_regmap(struct platform_device *pdev, const struct berlin_pinctrl_desc *desc, struct regmap *regmap); +void berlin_pinctrl_free_funcgroups(struct berlin_pinctrl *pctrl); + +static inline int berlin_pinctrl_remove(struct platform_device *pdev) +{ + struct berlin_pinctrl *pctrl = platform_get_drvdata(pdev); + + berlin_pinctrl_free_funcgroups(pctrl); + kfree(pctrl->functions); + return 0; +} #endif /* __PINCTRL_BERLIN_H */ -- 1.8.5.6 -- Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails 2016-10-12 12:36 ` Johannes Thumshirn @ 2016-10-12 17:06 ` Dan Carpenter 2016-10-13 13:09 ` Johannes Thumshirn 0 siblings, 1 reply; 10+ messages in thread From: Dan Carpenter @ 2016-10-12 17:06 UTC (permalink / raw) To: Johannes Thumshirn; +Cc: Linus Walleij, linux-gpio On Wed, Oct 12, 2016 at 02:36:16PM +0200, Johannes Thumshirn wrote: > +void berlin_pinctrl_free_funcgroups(struct berlin_pinctrl *pctrl) > +{ > + struct berlin_desc_group const *desc_group; > + struct berlin_desc_function const *desc_function; > + int i; > + > + for (i = 0; i < pctrl->desc->ngroups; i++) { > + desc_group = pctrl->desc->groups + i; > + desc_function = desc_group->functions; > + > + while (desc_function->name) { > + struct berlin_pinctrl_function > + *function = pctrl->functions; > + > + kfree(function->groups); It looks like, we're just freeing pctrl->functions->groups over and over. Not taking advantage of managed allocations has made this stuff so much more complicated. I'd be tempted almost to just delete the krealloc() and waste a little RAM... (I have no idea how much RAM I'm talking about here so maybe this is a bad idea). > + desc_function++; > + } > + } > +} > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails 2016-10-12 17:06 ` Dan Carpenter @ 2016-10-13 13:09 ` Johannes Thumshirn 2016-10-18 12:34 ` Linus Walleij 0 siblings, 1 reply; 10+ messages in thread From: Johannes Thumshirn @ 2016-10-13 13:09 UTC (permalink / raw) To: Dan Carpenter; +Cc: Linus Walleij, linux-gpio On Wed, Oct 12, 2016 at 08:06:40PM +0300, Dan Carpenter wrote: > On Wed, Oct 12, 2016 at 02:36:16PM +0200, Johannes Thumshirn wrote: > > > +void berlin_pinctrl_free_funcgroups(struct berlin_pinctrl *pctrl) > > +{ > > + struct berlin_desc_group const *desc_group; > > + struct berlin_desc_function const *desc_function; > > + int i; > > + > > + for (i = 0; i < pctrl->desc->ngroups; i++) { > > + desc_group = pctrl->desc->groups + i; > > + desc_function = desc_group->functions; > > + > > + while (desc_function->name) { > > + struct berlin_pinctrl_function > > + *function = pctrl->functions; > > + > > + kfree(function->groups); > > It looks like, we're just freeing pctrl->functions->groups over and > over. > > Not taking advantage of managed allocations has made this stuff so much > more complicated. I'd be tempted almost to just delete the krealloc() > and waste a little RAM... (I have no idea how much RAM I'm talking > about here so maybe this is a bad idea). Hmm yes. But I think it's best to just drop the patch from linux-pinctrl/for-next (and the sunxi one as well as it's suffering from the same pain). Let's get it back to the less broken state it has been in. @Linus are you ok with dropping these patches from your queue or shall I send you reverts? Byte, Johannes -- Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails 2016-10-13 13:09 ` Johannes Thumshirn @ 2016-10-18 12:34 ` Linus Walleij 2016-10-18 14:12 ` Johannes Thumshirn 0 siblings, 1 reply; 10+ messages in thread From: Linus Walleij @ 2016-10-18 12:34 UTC (permalink / raw) To: Johannes Thumshirn; +Cc: Dan Carpenter, linux-gpio@vger.kernel.org On Thu, Oct 13, 2016 at 3:09 PM, Johannes Thumshirn <jthumshirn@suse.de> wrote: > @Linus are you ok with dropping these patches from your queue or shall I send > you reverts? Dropping them, rebasing my for-next test branch on v4.9-rc1 anyway. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails 2016-10-18 12:34 ` Linus Walleij @ 2016-10-18 14:12 ` Johannes Thumshirn 0 siblings, 0 replies; 10+ messages in thread From: Johannes Thumshirn @ 2016-10-18 14:12 UTC (permalink / raw) To: Linus Walleij; +Cc: Dan Carpenter, linux-gpio@vger.kernel.org On Tue, Oct 18, 2016 at 02:34:23PM +0200, Linus Walleij wrote: > On Thu, Oct 13, 2016 at 3:09 PM, Johannes Thumshirn <jthumshirn@suse.de> wrote: > > > @Linus are you ok with dropping these patches from your queue or shall I send > > you reverts? > > Dropping them, rebasing my for-next test branch on v4.9-rc1 anyway. Thanks, Johannes -- Johannes Thumshirn Storage jthumshirn@suse.de +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-10-18 14:12 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-10-12 8:14 [bug report] pinctrl: berlin: Don't leak memory if krealloc() fails Dan Carpenter 2016-10-12 8:30 ` Johannes Thumshirn 2016-10-12 8:45 ` Dan Carpenter 2016-10-12 9:44 ` Johannes Thumshirn 2016-10-12 11:19 ` Dan Carpenter 2016-10-12 12:36 ` Johannes Thumshirn 2016-10-12 17:06 ` Dan Carpenter 2016-10-13 13:09 ` Johannes Thumshirn 2016-10-18 12:34 ` Linus Walleij 2016-10-18 14:12 ` Johannes Thumshirn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).