On Tue, Jun 09, 2015 at 04:38:40PM +0200, Gabriel Laskar wrote:
> On Tue, 9 Jun 2015 16:29:31 +0200
> Patrik Jakobsson <patrik.jakobsson@xxxxxxxxxxxxxxx> wrote:
>
> > On Tue, Jun 09, 2015 at 03:51:08PM +0200, Gabriel Laskar wrote:
> > > On Tue, 9 Jun 2015 13:26:44 +0200
> > > Patrik Jakobsson <patrik.jakobsson@xxxxxxxxxxxxxxx> wrote:
> > >
> > > > This patch adds many of the DRM and KMS ioctls. The rest can be added as
> > > > needed.
> > > >
> > > > Signed-off-by: Patrik Jakobsson <patrik.jakobsson@xxxxxxxxxxxxxxx>
> > > > ---
> > > > drm.c | 519 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > > 1 file changed, 519 insertions(+)
> > > >
> > > > diff --git a/drm.c b/drm.c
> > > > index fa98fb7..e550c34 100644
> > > > --- a/drm.c
> > > > +++ b/drm.c
> > > > @@ -82,6 +82,468 @@ int drm_is_driver(struct tcb *tcp, const char *name)
> > > > return strcmp(name, drv) == 0;
> > > > }
> > > >
> > > > +static int drm_version(struct tcb *tcp, const unsigned int code, long arg)
> > > > +{
> > > > + struct drm_version ver;
> > > > + char *name, *date, *desc;
> > > > + int ret;
> > > > +
> > > > + if (entering(tcp) || umove(tcp, arg, &ver))
> > > > + return 0;
> > > > +
> > > > + name = calloc(ver.name_len + 1, 1);
> > >
> > > We have some wrappers for that now, you can call xcalloc(), but it will
> > > die if this does not work. Your version have the advantage of not kill
> > > strace, and just not decode the argument.
> > >
> >
> > If ok I'll keep it as calloc? As you say, dying here is not really neccessary.
>
> Yeah, that was mostly me thinking out loud. Imho, I would keep the
> calloc(), but I don't know what Dmitry will prefer. Maybe for
> consistency, it should be better to have an xcalloc().
The general rule is to call xcalloc() if die_out_of_memory() is the best
way to handle the OOM condition. strace should neither attempt to
allocate arbitrary large chunks of memory specified by user input
nor die when such allocation requests fail.
--
ldv
Attachment:
pgpvSYaONnQGv.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
