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