From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: READ THIS: Modern driver coding practices
Date: Thu, 11 Dec 2014 20:52:29 +0000 [thread overview]
Message-ID: <20141211205229.GU11285@n2100.arm.linux.org.uk> (raw)
Today, ARM is a fully fledged architecture which supports many of the
mainstream features such as highmem. Highmem gets used if you have
more than about 600 to 800MB of memory, which in todays modern ARM
platforms, is most of them.
What this means is that drivers should be appropriately coded to take
account of highmem buffers being passed to the driver.
What prompted this email is network drivers. This is especially true
of network device drivers, especially when they support the NETIF_F_SG
(scatter-gather) feature.
This evening, I have come across two netdev drivers, and there is a
third known about, which implement the scatter-gather and TSO features,
but do this:
address = page_address(frag->page.p) + frag->page_offset;
dma_map_single(dev, address, ...);
This is buggy: frag->page.p may very well be a highmem page. When a
highmem page is used here, page_address() will be NULL, which will
then be passed into dma_map_single().
With the asm-generic implementation of dma_map_single(), we will
attempt to convert the address (which is now a NULL pointer) back
to a struct page pointer and offset. The result on Dove is either a
silent kernel lockup, or a kernel oops - but depending on the
virt-to-phys offset, this can end up hitting almost any address in
the system - and if it is successfully converted back to a physical
address, we could end up /silently/ invalidating the cache for
unintended addresses.
Please ensure that you appropriately consider highmem issues in your
driver if the subsystem for your driver can pass you highmem pages.
Moreover, please check whether the driver you are working on needs
to take account of highmem, and check that it appropriately does.
And most importantly, don't strip out highmem support "to make the
driver more simple" - that's what has happened to one of the drivers
which used to work fine but now oopses because of this for me.
Thanks.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
reply other threads:[~2014-12-11 20:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141211205229.GU11285@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).