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 > >> > > >> > > >> > _______________________________________________ > >> > 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
