[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] ofdisk: allocate space for vscsi table
|
From: |
Paulo Flabiano Smorigo |
|
Subject: |
Re: [PATCH] ofdisk: allocate space for vscsi table |
|
Date: |
Tue, 10 Nov 2015 21:31:41 -0200 |
On Mon, Nov 9, 2015 at 2:49 PM, Vladimir 'phcoder' Serbinenko
<address@hidden> wrote:
>
> Le 9 nov. 2015 5:34 PM, "Paulo Flabiano Smorigo" <address@hidden> a
> écrit :
>>
>> 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?
>>
> Sure, add this as a comment
Done. Commit ID: a50dbb743e53e5e643f27daa84261e6e9d7747c1
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > 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
>> >
>>
>> _______________________________________________
>> 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
>