* [PATCH] ofdisk: allocate space for vscsi table
@ 2015-11-09 1:33 Paulo Flabiano Smorigo
2015-11-09 10:46 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 7+ messages in thread
From: Paulo Flabiano Smorigo @ 2015-11-09 1:33 UTC (permalink / raw)
To: The development of GNU GRUB; +Cc: Paulo Flabiano Smorigo
The table must be allocated in order to avoid memory leak. Also added some
vscsi paths for illustration purpose.
---
grub-core/disk/ieee1275/ofdisk.c | 30 +++++++++++++++++++++++++-----
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/grub-core/disk/ieee1275/ofdisk.c b/grub-core/disk/ieee1275/ofdisk.c
index afec9ba..4ea6089 100644
--- a/grub-core/disk/ieee1275/ofdisk.c
+++ b/grub-core/disk/ieee1275/ofdisk.c
@@ -211,6 +211,11 @@ dev_iterate (const struct grub_ieee1275_devalias *alias)
{
if (grub_strcmp (alias->type, "vscsi") == 0)
{
+ /* Example of vscsi paths:
+ * /vdevice/v-scsi@30000002/disk@8100000000000000
+ * /vdevice/v-scsi@30000002/disk@8200000000000000
+ * /vdevice/v-scsi@30000002/disk@8400000000000000 */
+
static grub_ieee1275_ihandle_t ihandle;
struct set_color_args
{
@@ -222,27 +227,41 @@ dev_iterate (const struct grub_ieee1275_devalias *alias)
grub_ieee1275_cell_t table;
}
args;
- char *buf, *bufptr;
+ char *buf, *bufptr, *table;
unsigned i;
+ grub_uint32_t table_size;
if (grub_ieee1275_open (alias->path, &ihandle))
return;
-
+
+ /* 64 entries should be enough */
+ table_size = sizeof (grub_uint64_t) * 64;
+ table = grub_malloc (table_size);
+
+ if (!table)
+ return;
+
INIT_IEEE1275_COMMON (&args.common, "call-method", 2, 3);
args.method = (grub_ieee1275_cell_t) "vscsi-report-luns";
args.ihandle = ihandle;
- args.table = 0;
+ args.table = (grub_ieee1275_cell_t) table;
args.nentries = 0;
if (IEEE1275_CALL_ENTRY_FN (&args) == -1 || args.catch_result)
{
grub_ieee1275_close (ihandle);
- return;
+ grub_free (table);
+ return;
}
buf = grub_malloc (grub_strlen (alias->path) + 32);
if (!buf)
- return;
+ {
+ grub_ieee1275_close (ihandle);
+ grub_free (table);
+ return;
+ }
+
bufptr = grub_stpcpy (buf, alias->path);
for (i = 0; i < args.nentries; i++)
@@ -257,6 +276,7 @@ dev_iterate (const struct grub_ieee1275_devalias *alias)
}
}
grub_ieee1275_close (ihandle);
+ grub_free (table);
grub_free (buf);
return;
}
--
2.1.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] ofdisk: allocate space for vscsi table
2015-11-09 1:33 [PATCH] ofdisk: allocate space for vscsi table Paulo Flabiano Smorigo
@ 2015-11-09 10:46 ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-11-09 11:59 ` Paulo Flabiano Smorigo
0 siblings, 1 reply; 7+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2015-11-09 10:46 UTC (permalink / raw)
To: The development of GNU GRUB
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
On 09.11.2015 02:33, Paulo Flabiano Smorigo wrote:
> + /* 64 entries should be enough */
> + table_size = sizeof (grub_uint64_t) * 64;
Can we do something better than assuming a particular upper limit? You
don't even pass this limit to the function in any way. You basically get
a buffer overflow. Should we perhaps pass the limit in nentries? Or do
something similar?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ofdisk: allocate space for vscsi table
2015-11-09 10:46 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2015-11-09 11:59 ` Paulo Flabiano Smorigo
2015-11-09 12:03 ` Vladimir 'phcoder' Serbinenko
0 siblings, 1 reply; 7+ messages in thread
From: Paulo Flabiano Smorigo @ 2015-11-09 11:59 UTC (permalink / raw)
To: The development of GNU GRUB
On Mon, Nov 9, 2015 at 8:46 AM, Vladimir 'φ-coder/phcoder' Serbinenko
<phcoder@gmail.com> wrote:
> On 09.11.2015 02:33, Paulo Flabiano Smorigo wrote:
>> + /* 64 entries should be enough */
>> + table_size = sizeof (grub_uint64_t) * 64;
> Can we do something better than assuming a particular upper limit? You
> don't even pass this limit to the function in any way. You basically get
> a buffer overflow. Should we perhaps pass the limit in nentries? Or do
> something similar?
For sas there is an input attribute called max that I use as an upper
limit. AFAIK, vscsi method doesn't have it. nentries is a output
attribute.
I'll investigate it.
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ofdisk: allocate space for vscsi table
2015-11-09 11:59 ` Paulo Flabiano Smorigo
@ 2015-11-09 12:03 ` Vladimir 'phcoder' Serbinenko
2015-11-09 16:33 ` Paulo Flabiano Smorigo
0 siblings, 1 reply; 7+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2015-11-09 12:03 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]
Le 9 nov. 2015 1:00 PM, "Paulo Flabiano Smorigo" <pfsmorigo@gmail.com> a
écrit :
>
> On Mon, Nov 9, 2015 at 8:46 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
> > On 09.11.2015 02:33, Paulo Flabiano Smorigo wrote:
> >> + /* 64 entries should be enough */
> >> + table_size = sizeof (grub_uint64_t) * 64;
> > Can we do something better than assuming a particular upper limit? You
> > don't even pass this limit to the function in any way. You basically get
> > a buffer overflow. Should we perhaps pass the limit in nentries? Or do
> > something similar?
>
> For sas there is an input attribute called max that I use as an upper
> limit. AFAIK, vscsi method doesn't have it. nentries is a output
> attribute.
>
> I'll investigate it.
>
Can't we just properly free returned memory? Or perhaps even just tolerate
the leak and only ensure that it happens only once per controller per GRUB
run?
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
[-- Attachment #2: Type: text/html, Size: 1904 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ofdisk: allocate space for vscsi table
2015-11-09 12:03 ` Vladimir 'phcoder' Serbinenko
@ 2015-11-09 16:33 ` Paulo Flabiano Smorigo
2015-11-09 16:49 ` Vladimir 'phcoder' Serbinenko
0 siblings, 1 reply; 7+ messages in thread
From: Paulo Flabiano Smorigo @ 2015-11-09 16:33 UTC (permalink / raw)
To: The development of GNU GRUB
On Mon, Nov 9, 2015 at 10:03 AM, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
>
> Le 9 nov. 2015 1:00 PM, "Paulo Flabiano Smorigo" <pfsmorigo@gmail.com> a
> écrit :
>>
>> On Mon, Nov 9, 2015 at 8:46 AM, Vladimir 'φ-coder/phcoder' Serbinenko
>> <phcoder@gmail.com> wrote:
>> > On 09.11.2015 02:33, Paulo Flabiano Smorigo wrote:
>> >> + /* 64 entries should be enough */
>> >> + table_size = sizeof (grub_uint64_t) * 64;
>> > Can we do something better than assuming a particular upper limit? You
>> > don't even pass this limit to the function in any way. You basically get
>> > a buffer overflow. Should we perhaps pass the limit in nentries? Or do
>> > something similar?
>>
>> For sas there is an input attribute called max that I use as an upper
>> limit. AFAIK, vscsi method doesn't have it. nentries is a output
>> attribute.
>>
>> I'll investigate it.
>>
> Can't we just properly free returned memory? Or perhaps even just tolerate
> the leak and only ensure that it happens only once per controller per GRUB
> run?
Talked to the Open firmware team and we don't need to allocate the
space. The vscsi implementation takes care of all of the memory
management. The result of the call stays in a reserved memory and is
never freed.
For vscsi-report-luns method there are no input values.
So, this patch isn't necessary. Should I put this info as a comment in the code?
>> >
>> >
>> > _______________________________________________
>> > Grub-devel mailing list
>> > Grub-devel@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/grub-devel
>> >
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ofdisk: allocate space for vscsi table
2015-11-09 16:33 ` Paulo Flabiano Smorigo
@ 2015-11-09 16:49 ` Vladimir 'phcoder' Serbinenko
2015-11-10 23:31 ` Paulo Flabiano Smorigo
0 siblings, 1 reply; 7+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2015-11-09 16:49 UTC (permalink / raw)
To: The development of GRUB 2
[-- Attachment #1: Type: text/plain, Size: 2323 bytes --]
Le 9 nov. 2015 5:34 PM, "Paulo Flabiano Smorigo" <pfsmorigo@gmail.com> a
écrit :
>
> On Mon, Nov 9, 2015 at 10:03 AM, Vladimir 'phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
> >
> > Le 9 nov. 2015 1:00 PM, "Paulo Flabiano Smorigo" <pfsmorigo@gmail.com> a
> > écrit :
> >>
> >> On Mon, Nov 9, 2015 at 8:46 AM, Vladimir 'φ-coder/phcoder' Serbinenko
> >> <phcoder@gmail.com> wrote:
> >> > On 09.11.2015 02:33, Paulo Flabiano Smorigo wrote:
> >> >> + /* 64 entries should be enough */
> >> >> + table_size = sizeof (grub_uint64_t) * 64;
> >> > Can we do something better than assuming a particular upper limit?
You
> >> > don't even pass this limit to the function in any way. You basically
get
> >> > a buffer overflow. Should we perhaps pass the limit in nentries? Or
do
> >> > something similar?
> >>
> >> For sas there is an input attribute called max that I use as an upper
> >> limit. AFAIK, vscsi method doesn't have it. nentries is a output
> >> attribute.
> >>
> >> I'll investigate it.
> >>
> > Can't we just properly free returned memory? Or perhaps even just
tolerate
> > the leak and only ensure that it happens only once per controller per
GRUB
> > run?
>
> Talked to the Open firmware team and we don't need to allocate the
> space. The vscsi implementation takes care of all of the memory
> management. The result of the call stays in a reserved memory and is
> never freed.
>
> For vscsi-report-luns method there are no input values.
>
> So, this patch isn't necessary. Should I put this info as a comment in
the code?
>
Sure, add this as a comment
> >> >
> >> >
> >> > _______________________________________________
> >> > Grub-devel mailing list
> >> > Grub-devel@gnu.org
> >> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >> >
> >>
> >> _______________________________________________
> >> Grub-devel mailing list
> >> Grub-devel@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
[-- Attachment #2: Type: text/html, Size: 3698 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] ofdisk: allocate space for vscsi table
2015-11-09 16:49 ` Vladimir 'phcoder' Serbinenko
@ 2015-11-10 23:31 ` Paulo Flabiano Smorigo
0 siblings, 0 replies; 7+ messages in thread
From: Paulo Flabiano Smorigo @ 2015-11-10 23:31 UTC (permalink / raw)
To: The development of GNU GRUB
On Mon, Nov 9, 2015 at 2:49 PM, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
>
> Le 9 nov. 2015 5:34 PM, "Paulo Flabiano Smorigo" <pfsmorigo@gmail.com> a
> écrit :
>>
>> On Mon, Nov 9, 2015 at 10:03 AM, Vladimir 'phcoder' Serbinenko
>> <phcoder@gmail.com> wrote:
>> >
>> > Le 9 nov. 2015 1:00 PM, "Paulo Flabiano Smorigo" <pfsmorigo@gmail.com> a
>> > écrit :
>> >>
>> >> On Mon, Nov 9, 2015 at 8:46 AM, Vladimir 'φ-coder/phcoder' Serbinenko
>> >> <phcoder@gmail.com> wrote:
>> >> > On 09.11.2015 02:33, Paulo Flabiano Smorigo wrote:
>> >> >> + /* 64 entries should be enough */
>> >> >> + table_size = sizeof (grub_uint64_t) * 64;
>> >> > Can we do something better than assuming a particular upper limit?
>> >> > You
>> >> > don't even pass this limit to the function in any way. You basically
>> >> > get
>> >> > a buffer overflow. Should we perhaps pass the limit in nentries? Or
>> >> > do
>> >> > something similar?
>> >>
>> >> For sas there is an input attribute called max that I use as an upper
>> >> limit. AFAIK, vscsi method doesn't have it. nentries is a output
>> >> attribute.
>> >>
>> >> I'll investigate it.
>> >>
>> > Can't we just properly free returned memory? Or perhaps even just
>> > tolerate
>> > the leak and only ensure that it happens only once per controller per
>> > GRUB
>> > run?
>>
>> Talked to the Open firmware team and we don't need to allocate the
>> space. The vscsi implementation takes care of all of the memory
>> management. The result of the call stays in a reserved memory and is
>> never freed.
>>
>> For vscsi-report-luns method there are no input values.
>>
>> So, this patch isn't necessary. Should I put this info as a comment in the
>> code?
>>
> Sure, add this as a comment
Done. Commit ID: a50dbb743e53e5e643f27daa84261e6e9d7747c1
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Grub-devel mailing list
>> >> > Grub-devel@gnu.org
>> >> > https://lists.gnu.org/mailman/listinfo/grub-devel
>> >> >
>> >>
>> >> _______________________________________________
>> >> Grub-devel mailing list
>> >> Grub-devel@gnu.org
>> >> https://lists.gnu.org/mailman/listinfo/grub-devel
>> >
>> >
>> > _______________________________________________
>> > Grub-devel mailing list
>> > Grub-devel@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/grub-devel
>> >
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-11-10 23:32 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-11-09 1:33 [PATCH] ofdisk: allocate space for vscsi table Paulo Flabiano Smorigo
2015-11-09 10:46 ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-11-09 11:59 ` Paulo Flabiano Smorigo
2015-11-09 12:03 ` Vladimir 'phcoder' Serbinenko
2015-11-09 16:33 ` Paulo Flabiano Smorigo
2015-11-09 16:49 ` Vladimir 'phcoder' Serbinenko
2015-11-10 23:31 ` Paulo Flabiano Smorigo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.