netdev - NETIF_F

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

Message-ID: <52FBFD03.6000703@cogentembedded.com>
Date:	Thu, 13 Feb 2014 02:00:19 +0300
From:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: NETIF_F_HIGHDMA?

Hello.

    I fail to understand why this flag is needed at all. netdev-features.txt says:

  * Transmit DMA from high memory

On platforms where this is relevant, NETIF_F_HIGHDMA signals that
ndo_start_xmit can handle skbs with frags in high memory.

    TTBOMK, highmem is an area of the kernel *virtual* memory that maps 
physical memory that can't be directly mapped unto the linear kernel space, 
i.e. in case when there's more memory in the system than the kernel memory can 
directly map. But what this has to do with DMA which deals with the physical 
memory? High memory doesn't have to be beyond 4 GiB limit -- it can exist even 
on 32-bit system (consider 4 GiB memory and 2/2 or 3/1 GiB user/kernel VM 
split), contrary to the belief of the many Ethernet PCI drivers which only set 
NETIF_F_HIGHDMA when the PCI dual address cycle is supported (i.e. the address 
on PCI can be 64-bit)...

    So, in my opinion, each and every driver should set this flag (except 
maybe those arch-specific drivers where CONFIG_HIGHMEM is not supported but 
even it this case the flag wouldn't hurt), and hence it's not needed at all. 
What am I missing in my picture?

WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html