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

Powered by blists - more mailing lists