From: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
To: Viral Mehta <Viral.Mehta@lntinfotech.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Cc: Kyungmin Park <kyungmin.park@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] USB: gadget: f_mass_storage: fix in fsg_common_init() error recovery
Date: Wed, 12 May 2010 11:53:45 +0200 [thread overview]
Message-ID: <op.vck63vc77p4s8u@pikus> (raw)
In-Reply-To: <70376CA23424B34D86F1C7DE6B9973430254343ABB@VSHINMSMBX01.vshodc.lntinfotech.com>
>> fsg_common_init() as a first argument takes a pointer to a fsg_common
>> structure which, if not NULL, is reused and it is then assumed that
>> caller is responsible far maintaining allocation and deallocation of
>> this structure.
>>
>> The idea is that one can do:
>>
>> static struct fsg_common fsg_common;
>> /* ... */
>> fsg_common_init(&fsg_common, cdev, fsg_config);
>>
>> or allocate fsg_common structure as a part of a larger structure. In such
>> cases kfree() cannot be called on the object. Which case we are dealing
>> with is indicated by the common->free_storage_on_release flag.
>> fsg_common_release() consults it and either calls or does not call krfee().
On Wed, 12 May 2010 11:28:31 +0200, Viral Mehta <Viral.Mehta@lntinfotech.com> wrote:
> Oh, makes sense. All instances has fsg_common_init(0, ...) and so i just missed...
I'm preparing a some patches for g_multi which change that.
Also, a change for g_mass_storage which uses a static memory would be like 10 line
patch which I may submit later.
> But, still the central idea was, why should we go to whole error_release path which
> really does removing device file and closing luns and etc.
> However, it will not make any difference since curlun->nluns will be zero and so
> there will be no loop in fsg_common_releas() function.
The way I see it, it does not matter that much -- it's error recovery so we assume
it's unlikely to happen and as such speed optimisation is not really needed here --
it's better to optimise for space and minimise the number of possible paths.
> Apart from that, IMHO,
> 2894 kfree(common->luns);
> should crash in case if your error path is followed.
>
> common->luns is allocd
> 2712 /* Create the LUNs, open their backing files, and register the
> 2713 * LUN devices in sysfs. */
> 2714 curlun = kzalloc(nluns * sizeof *curlun, GFP_KERNEL);
> 2715 if (!curlun) {
> 2716 kfree(common);
> 2717 return ERR_PTR(-ENOMEM);
> 2718 }
Yes, that's why the submitted patch changes that to "rc = -ENOMEM;
goto errer_release;".
--
Best regards, _ _
| Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
| Computer Science, Michał "mina86" Nazarewicz (o o)
+----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo--
next prev parent reply other threads:[~2010-05-12 9:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-12 8:16 [PATCH] USB: gadget: f_mass_storage: fix in fsg_common_init() error recovery Michal Nazarewicz
2010-05-12 8:29 ` Viral Mehta
2010-05-12 9:02 ` Michał Nazarewicz
2010-05-12 9:28 ` Viral Mehta
2010-05-12 9:36 ` Viral Mehta
2010-05-12 9:57 ` Michał Nazarewicz
2010-05-12 10:33 ` Viral Mehta
2010-05-12 10:51 ` [PATCH] USB: gadget: f_mass_storage: fix in " Michal Nazarewicz
2010-05-12 12:03 ` Viral Mehta
2010-05-12 21:39 ` Greg KH
2010-05-12 22:16 ` Michal Nazarewicz
2010-05-12 9:53 ` Michał Nazarewicz [this message]
2010-05-12 10:06 ` [PATCH] USB: gadget: f_mass_storage: fix in fsg_common_init() " Viral Mehta
2010-05-12 10:34 ` Michał Nazarewicz
2010-05-12 10:37 ` Viral Mehta
2010-05-12 10:52 ` Michał Nazarewicz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.vck63vc77p4s8u@pikus \
--to=m.nazarewicz@samsung.com \
--cc=Viral.Mehta@lntinfotech.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox