linux-kernel - Question of resource

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>] [day] [month] [year] [list]

Date:	Wed, 30 Dec 2009 01:43:54 +0200
From:	Felipe Balbi <me@...ipebalbi.com>
To:	linux-kernel@...r.kernel.org
Subject: Question of resource_size() implementation

Hi all,

I'm wondering whether the +1 in resource_size() is actually necessary.
To illustrate the problem imagine we have two subsequent 4k memory areas
which should be passed to ioremap(). When passing those address spaces
to the drivers we will use struct resource and define something like:

#define MEM_AREA1_BASE	0x480ab000
#define MEM_AREA2_BASE	0x480ac000

struct resource my_device_resources = {
	{
		.start	= MEM_AREA1_BASE,
		.end	= MEM_AREA1_BASE + SZ_4K - 1,
		.flags	= IORESOURCE_MEM,
	},
	{
		.start	= MEM_AREA2_BASE,
		.end	= MEM_AREA2_BASE + SZ_4K - 1,
		.flags	= IORESOURCE_MEM,
	},
};

that -1 would cause us to pass the correct end for each area,
respectively 0x480abfff and 0x480acffff, right ?

But resource_size() is defined as:

static inline resource_size_t resource_size(const struct resource *res)
{
	return res->end - res->start + 1;
}

then we put +1 again and the end addresses would then become
respectively 0x480ac000 and 0x480ad0000. Wouldn't we then fail ioremap()
of the second area ? wouldn't it return -EBUSY ? Are we off-by-one
here ? Or is this all expected ?

I have to say, I didn't test this on real hw yet...

-- 
balbi

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