linux-kernel - Re: [PATCH 11/16 v2] Input: atmel_mxt_ts

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]

Message-ID: <20120413110904.GA4842@polaris.bitmath.org>
Date:	Fri, 13 Apr 2012 13:09:04 +0200
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Daniel Kurtz <djkurtz@...omium.org>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Nick Dyer <nick.dyer@...ev.co.uk>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, Benson Leung <bleung@...omium.org>,
	Yufeng Shen <miletus@...omium.org>
Subject: Re: [PATCH 11/16 v2] Input: atmel_mxt_ts - refactor reading object
 table

> > I am talking about the data that is being read here and written in
> > mxt_check_reg_init(). By matching the struct with that data, all the
> > copies you make would go away.
> 
> The data read here is a table of object descriptors.  The data written
> in mxt_check_reg_init() is configuration data for each of the objects
> described by the descriptors.  What copies are you talking about?

In this patch, the object descriptors are read into a buffer, then
copied over to the object struct that you hold. That is the copy that
obviously goes away if the data is copied directly into the suggested
struct. In patch 9, you copy an unknown amount of data over to a
stack-allocated buffer before sending it via ic2. That is the main
technichal concern, and it was the first question you got, some days
ago.

> The config array in platform_data is a single big long array that has
> to be manually created in a platform file.  It just has blobs of data
> for each of the 'writable' objects for a given device, all
> concatenated together.

Ok, so no need for the second suggested struct or anything of that
kind. Just sort out the maximum blob size and, if necessary, avoid the
stack allocation in mxt_check_reg_init(), and it should be fine.

Henrik
--
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/