The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Corey Minyard <minyard@acm.org>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Problem with NETIF_F_HIGHDMA
Date: Wed, 22 Feb 2006 12:47:15 -0600	[thread overview]
Message-ID: <43FCB1B3.8090101@acm.org> (raw)

I was looking at a problem with a new system we are trying to get up and
running.  It has a 32-bit only PCI network device, but is a 64-bit
(x86_64) system.  Looking at the code for NETIF_F_HIGHDMA (which, when
not set on a PCI network device, means that it cannot do 64-bit
accesses) in net/core/dev.c, it seems wrong to me.

It is dependent on HIGHMEM, but HIGHMEM has nothing to do with 32/64 bit
accesses.  On 64-bit systems, HIGHMEM is not set, thus the network code
will pass any address (including those >32bits) to the driver.  Plus,
highmem on 32-bit systems may very well be 32-bit accessible, possibly
resulting in unecessary copies.  AFAICT, the current code will only work
with i386 and PAE and is sub-optimal.

If I am right, it is a little messy to fix, but I think doable.  I
propose the following:

    * Create a new zone named ZONE_HIGHMEM32 for 32-bit HIGHMEM addresses.
    * Modify 64-bit architectures (and i386 with HIGHMEM) to put the
      proper pages into the new zone.
    * Add a "PageIn32Bits()" function/macro to check for this, and use
      it in illegal_highdma() in net/core/dev.c
    * Allocate from ZONE_HIGHMEM32 if illegal_highdma() returns true.

I think this will solve the problem.  I haven't looked at other parts of
the kernel (IDE, SCSI, etc.) to see if they have similar problems.

Anyway, does the above change sound reasonable?  Maybe there's an easier
way?  Maybe I've missed something?

Thanks,

-Corey

             reply	other threads:[~2006-02-22 18:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-22 18:47 Corey Minyard [this message]
2006-02-22 18:51 ` Problem with NETIF_F_HIGHDMA Arjan van de Ven
2006-02-22 20:14   ` Corey Minyard
2006-02-22 20:21     ` Arjan van de Ven
2006-02-23 13:14       ` David Woodhouse
2006-02-22 19:07 ` Chris Wright
2006-02-22 20:45 ` Andi Kleen

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=43FCB1B3.8090101@acm.org \
    --to=minyard@acm.org \
    --cc=linux-kernel@vger.kernel.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