Re: [PATCH] ofdisk: allocate space for vscsi table

[Paulo Flabiano Smorigo]

On Mon, Nov 9, 2015 at 10:03 AM, Vladimir 'phcoder' Serbinenko
<address@hidden> wrote:
>
> Le 9 nov. 2015 1:00 PM, "Paulo Flabiano Smorigo" <address@hidden> a
> écrit :
>>
>> On Mon, Nov 9, 2015 at 8:46 AM, Vladimir 'φ-coder/phcoder' Serbinenko
>> <address@hidden> 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
>> > address@hidden
>> > https://lists.gnu.org/mailman/listinfo/grub-devel
>> >
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>