lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 20 Nov 2006 12:05:21 -0800
From:	Andrew Morton <akpm@...l.org>
To:	James Simmons <jsimmons@...radead.org>
Cc:	linux-fbdev-devel@...ts.sourceforge.net,
	Tero Roponen <teanropo@....fi>, linux-kernel@...r.kernel.org
Subject: Re: [Linux-fbdev-devel] fb: modedb uses wrong default_mode

On Mon, 20 Nov 2006 16:48:05 +0000 (GMT)
James Simmons <jsimmons@...radead.org> wrote:

> > > 	    db = modedb;
> > > 	dbsize = ARRAY_SIZE(modedb);
> > > 
> > > 	if (!default_mode)
> > > 	    default_mode = &db[DEFAULT_MODEDB_INDEX];
> > > 	if (!default_bpp)
> > > 	    default_bpp = 8;
> > > 
> > > db will always be set.
> > 
> > I think we do need dbsize, and that the code which I have now:
> 
> I really don't trust dbsize. The driver writer can pass in the wrong 
> number.

That would be a bug.

> Whereas ARRAY_SIZE will always be correct. Lets take the position 
> that we use dbsize then we need to test if dbsize is greater than the 
> really size of the modedb. The dbsize parameter was for the days before we
> had ARRAY_SIZE.
> 
> > int fb_find_mode(struct fb_var_screeninfo *var,
> > 		 struct fb_info *info, const char *mode_option,
> > 		 const struct fb_videomode *db, unsigned int dbsize,
> > 		 const struct fb_videomode *default_mode,
> > 		 unsigned int default_bpp)
> > {
> >     int i;
> > 
> >     /* Set up defaults */
> >     if (!db) {
> > 	db = modedb;
> > 	dbsize = ARRAY_SIZE(modedb);
> >     }
> 
>       if (dbsize > ARRAY_SIZE(db))
> 	dbsize = ARRAY_SIZE(db);

We can't do ARRAY_SIZE on a random pointer like this: the compiler needs to
see the full definition of the array itself, and that is back in the
caller's compilation unit.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ