linux-kernel - Re: [RFC PATCH 07/11] coresight: add CoreSight ETM driver

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:	Tue, 03 Jun 2014 18:04:47 +0100
From:	Daniel Thompson <daniel.thompson@...aro.org>
To:	Mathieu Poirier <mathieu.poirier@...aro.org>
CC:	Linus Walleij <linus.walleij@...aro.org>,
	Will Deacon <will.deacon@....com>,
	Arve Hjønnevåg <arve@...roid.com>,
	John Stultz <john.stultz@...aro.org>,
	Pratik Patel <pratikp@...eaurora.org>,
	Vikas Varshney <varshney@...com>, Al Grant <Al.Grant@....com>,
	Jonas Svennebring <jonas.svennebring@...gotech.com>,
	James King <james.king@...aro.org>,
	Panchaxari Prasannamurthy Tumkur 
	<panchaxari.prasannamurthy@...aro.org>,
	Arnd Bergmann <arnd@...aro.org>,
	Marcin Jabrzyk <marcin.jabrzyk@...il.com>,
	r.sengupta@...sung.com, Robert Marklund <robbelibobban@...il.com>,
	Patch Tracking <patches@...aro.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 07/11] coresight: add CoreSight ETM driver

On 03/06/14 17:37, Mathieu Poirier wrote:
>>> +static ssize_t debugfs_status_read(struct file *file, char __user *user_buf,
>>> +                                size_t count, loff_t *ppos)
>>> +{
>>> +     ssize_t ret;
>>> +     uint32_t val;
>>> +     unsigned long flags;
>>> +     char *buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
>>> +     struct etm_drvdata *drvdata = file->private_data;
>>> +
>>> +     if (!buf)
>>> +             return -ENOMEM;
>>> +
>>> +     ret = clk_prepare_enable(drvdata->clk);
>>> +     if (ret)
>>> +             goto out;
>>> +
>>> +     spin_lock_irqsave(&drvdata->spinlock, flags);
>>> +
>>> +     ETM_UNLOCK(drvdata);
>>> +     val = etm_readl(drvdata, ETMCCR);
>>> +     ret += sprintf(buf, "ETMCCR: 0x%08x\n", val);
>>> +     val = etm_readl(drvdata, ETMCCER);
>>> +     ret += sprintf(buf + ret, "ETMCCER: 0x%08x\n", val);
>>> +     val = etm_readl(drvdata, ETMSCR);
>>> +     ret += sprintf(buf + ret, "ETMSCR: 0x%08x\n", val);
>>> +     val = etm_readl(drvdata, ETMIDR);
>>> +     ret += sprintf(buf + ret, "ETMIDR: 0x%08x\n", val);
>>> +     val = etm_readl(drvdata, ETMCR);
>>> +     ret += sprintf(buf + ret, "ETMCR: 0x%08x\n", val);
>>> +     val = etm_readl(drvdata, ETMTEEVR);
>>> +     ret += sprintf(buf + ret, "Enable event: 0x%08x\n", val);
>>> +     val = etm_readl(drvdata, ETMTSSCR);
>>> +     ret += sprintf(buf + ret, "Enable start/stop: 0x%08x\n", val);
>>> +     ret += sprintf(buf + ret,
>>> +                    "Enable control: CR1 0x%08x CR2 0x%08x\n",
>>> +                    etm_readl(drvdata, ETMTECR1),
>>> +                    etm_readl(drvdata, ETMTECR2));
>>> +
>>> +     ETM_LOCK(drvdata);
>>> +
>>> +     spin_unlock_irqrestore(&drvdata->spinlock, flags);
>>> +     clk_disable_unprepare(drvdata->clk);
>>> +
>>> +     ret = simple_read_from_buffer(user_buf, count, ppos, buf, ret);
>>> +out:
>>> +     kfree(buf);
>>> +     return ret;
>>> +}
>>
>> Really not sure whether this should be in the read method. If we don't
>> read the file in one go the spin_lock() we'll not get a cohesive set of
>> registers.
> 
> I get your point but since there is a possibility (even very remove)
> that any of these registers can be changed between the two read
> operations, the only reasonable solution I see is to return an error
> if  (ret > size).  What your opinion on that?

I'd prefer that we simply copy the approach used by simple_attr_read().


Daniel.
--
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/