netdev - Re: NIU driver unmap

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

Message-Id: <558C09D0-FEBE-4DC8-A137-AF40FF711A69@freescale.com>
Date:	Mon, 1 Jun 2009 15:58:32 -0500
From:	Andy Fleming <afleming@...escale.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: NIU driver unmap_page call


On Jun 1, 2009, at 5:11 AM, David Miller wrote:

> From: Andy Fleming <afleming@...escale.com>
> Date: Fri, 29 May 2009 17:38:50 -0500
>
>> I'm trying to figure out what this code does:
>>
>>               if ((page->index + rp->rbr_block_size) - rcr_size ==  
>> addr) {
>>                       *link = (struct page *) page->mapping;
>>                       np->ops->unmap_page(np->device, page->index,
>>                                           PAGE_SIZE,  
>> DMA_FROM_DEVICE);
>>                       page->index = 0;
>>                       page->mapping = NULL;
>>                       rp->rbr_refill_pending++;
>>               } else
>>                       get_page(page);
>>
>> It's clear it's taking the opportunity to remove the page from the
>> hash table, and to unmap the page, but I'm not familiar enough with
>> this nic to understand what the if statement is looking for.  My  
>> first
>> thought was that it was looking to see if this was the first buffer  
>> in
>> the page?
>
> It's looking to see if this is the LAST chunk in the page, not the
> first.


Hmm... I'm still misunderstanding something.  rbr_blocks_per_page  
implies that each page has multiple blocks.  This looks like it is  
checking to see if the current buffer is the last buffer in the  
block.  There is similar code in the niu_rx_pkt_ignore function, which  
uses PAGE_SIZE in place of rbr_block_size.


>
>
> rcr_size is the size of the sub-buffers within the page that the
> chip is carving out of the page.
>
> Since when we allocated the page initially this obtained on reference
> to the page, we increment for every chunk given out to an SKB except
> the last one.

But in niu_rbr_add_page(), the function does:

                 atomic_add(rp->rbr_blocks_per_page - 1,
                            &compound_head(page)->_count);

Which I thought was already doing the necessary accounting.

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