ip_rcv函數中調用skb_share_check克隆skb疑問

ljbphoebe

問：原來的skb哪去了？  
    ip_rcv函數處理從鏈路層來的skb數據包，該函數會檢查skb是否被共享，如果被共享就clone一個skb，原來的skb的user引用計數減1。
    如果skb的user引用數為3的話，那么就會進入skb_share_check中的if (skb_shared(skb)) 段中執(zhí)行，就會clone 一個新的skb，然后kfree_skb（skb）將舊的skb的引用計數減1，user為2，
    struct sk_buff *nskb = skb_clone(skb, pri);
                kfree_skb(skb);
                skb = nskb;
從代碼上看，skb指針指向了新clone的skb，kfree_skb(skb)并沒有真正釋放原來skb，那么原來的skb哪去了呢？豈不是內核內存泄露了？誰知道這是為什么？謝謝~

1. int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt)
   
2. {
   
3.         struct iphdr *iph;
   
4. 
   
5.         /* When the interface is in promisc. mode, drop all the crap
   
6.          * that it receives, do not try to analyse it.
   
7.          */
   
8.         if (skb->pkt_type == PACKET_OTHERHOST)
   
9.                 goto drop;
   
10. 
    
11.         IP_INC_STATS_BH(IPSTATS_MIB_INRECEIVES);
    
12. 
    
13.         if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) {
    
14.                 IP_INC_STATS_BH(IPSTATS_MIB_INDISCARDS);
    
15.                 goto out;
    
16.         }
    
17. ......
    
18. 
    
19. }
    
20. 
    
21. static inline struct sk_buff *skb_share_check(struct sk_buff *skb, int pri)
    
22. {
    
23.         might_sleep_if(pri & __GFP_WAIT);
    
24.         if (skb_shared(skb)) {
    
25.                 struct sk_buff *nskb = skb_clone(skb, pri);
    
26.                 kfree_skb(skb);
    
27.                 skb = nskb;
    
28.         }
    
29.         return skb;
    
30. }
    
31. 
    
32. static inline void kfree_skb(struct sk_buff *skb)
    
33. {
    
34.         if (atomic_read(&skb->users) == 1 || atomic_dec_and_test(&skb->users))
    
35.                 __kfree_skb(skb);
    
36. }
    

復制代碼

whaaat

按照你的假設skb的user傳進來時就是3，表明有其他地方使用這個skb，使用的地方會負責釋放的

ljbphoebe

我查看了原來的skb的出處，調用路徑是這樣的:
process_backlog函數中，skb = __skb_dequeue(&queue->input_pkt_queue);   此時的skb是孤立的個體，沒有其他指針指向它
然后調用netif_receive_skb(skb);       將skb和所有的已注冊的協議相比較，
然后調用deliver_skb(skb, pt_prev);       對user引用計數遞增，調用上層協議處理函數處理此skb，對于ip層，就直接調用ip_rcv函數了

多謝提醒啊，我明白了。感覺應該是這樣：
int netif_receive_skb(struct sk_buff *skb)
{
    ......

        list_for_each_entry_rcu(ptype, &ptype_all, list) {
                if (!ptype->dev || ptype->dev == skb->dev) {
                        if (pt_prev)
                                ret = deliver_skb(skb, pt_prev);
                        pt_prev = ptype;
                }
        }
     ........
        list_for_each_entry_rcu(ptype, &ptype_base[ntohs(type)&15], list) {
                if (ptype->type == type &&
                    (!ptype->dev || ptype->dev == skb->dev)) {
                        if (pt_prev)
                                ret = deliver_skb(skb, pt_prev);
                        pt_prev = ptype;
                }
        }
   .......
}

在每次比較協議的時候，都會調用相應協議的處理函數來對之前的skb操作，所以除了在ip層的ip_rcv函數之外，還有其他協議的處理函數操作此skb，應該是這樣了

hk_sean

路過看看，求更深入分析

ljbphoebe

從linux網絡內核源碼看，我也只是看大概的流程，沒有細看具體的細節(jié)

      每個網卡在linux啟動之初都跟內核相關聯上，硬件是內核函數pci_init()內部通過層層調用，最后通過pci_scan_device()函數將網卡結構掛著pci_devices全局變量上。網卡驅動程序是通過pci_register_driver ()函數將網卡驅動掛入全局驅動鏈表pci_drivers中，并且將驅動和對應的device相關聯。在網卡驅動結構struct pci_driver中，是一些函數指針，最主要的是probe，指向具體類型網卡相應的初始化函數，如rtl8139_init_one，這個函數是真正和具體網卡有直接關系的驅動程序，主要負責建立網卡設備結構net_device，申請中斷號，映射內存IO端口等任務。而在net_device結構中就是內核可以直接操作網卡的一系列函數指針open，hard_start_xmit，poll等等，net_device結構比較大，不能全列出來
struct net_device{
    ........
     int        (*open)(struct net_device *dev);
     int        (*stop)(struct net_device *dev);
     int        (*hard_start_xmit) (struct sk_buff *skb, struct net_device *dev);
     int        (*poll) (struct net_device *dev, int *quota);
   ........
}
      open指向rtl8139_open，hard_start_xmit指向rtl8139_start_xmit，poll指向rtl8139_poll，stop指向rtl8139_close函數，分別是打開設備，發(fā)送數據包，輪訓設備接收數據包，關閉設備。顯然打開和關閉設備分別在系統(tǒng)啟動和系統(tǒng)關閉時的操作；發(fā)送和接收是隨時的操作。在open操作中驅動程序會為此網卡申請一個中斷號，并且關聯上中斷服務程序。對于網絡接收數據包有兩種方式：1.中斷方式；2.輪訓方式
1.中斷方式：
      在2.4及2.4之前的內核是以中斷方式接收的，即中斷服務程序通過將接收到的數據拷貝到內核緩沖包結構skb中，然后通過netif_rx()函數將skb掛入軟中斷數據結構softnet_data結構中的input_pkt_queue隊列上，再通過netif_rx_schedule()函數將設備poll_list加入softnet_data的poll_list列表中并標記軟中斷，等待內核處理。這部分是硬中斷處理部分。
      內核在軟中斷處理時機，net_rx_action()函數調用process_backlog函數（也是poll，是blog_dev的poll，2.6中是backlog_dev）將skb從input_pkt_queue隊列取出，然后調用netif_receive_skb()函數將skb數據包提交給網絡上層。
struct softnet_data
{
   ……
        struct sk_buff_head        input_pkt_queue;
        struct list_head        poll_list;
   ……
};
2.輪訓方式：
      在2.6內核中增加了輪訓機制。這種機制，從我看內核源碼中發(fā)現，它不再將skb掛入input_pkt_queue了（不知道我看的對不對，有高手給予指正），在中斷服務程序中就不一樣了。當中斷到來時，它是先將對應設備的poll_list掛入struct softnet_data的poll_list列表中，然后打軟中斷標記，先不對數據包進行接收，把接收數據包的任務給軟中斷了。
      在軟中斷執(zhí)行時機，net_rx_action()調用poll函數將網卡數據交給skb，然后直接調用netif_receive_skb()函數交給上層。
      我感覺中斷和輪訓處理方式不同的是在接收skb數據包的時機不同了（雖然都用poll，但是poll處理數據包時機不同），中斷方式是在硬中斷過程中接收的，而輪訓方式是在軟中斷過程中接收的；另一個就是輪訓方式是不將skb保存在input_pkt_queue隊列中。對于這一點，我還不確定我看的對不對，希望大家討論一下

      接下來，netif_receive_skb()得到skb包之后就處理該數據包。先檢查包的正確性（netpoll_rx函數檢查），打時間戳，……，再之后就是掃描ptype_all鏈表與ptype_base哈希表。ptype_base是各種已經注冊的協議的哈希表，根據每個數據包協議不同分派給不同的協議來處理，在這里遞增skb進行索引計數，然后會在后續(xù)的操作中對skb進行拷貝。我們討論的是IP協議，所以就通過ETH_P_IP標志傳給IP層處理函數ip_rcv()，這是通過struct packet_type的func函數指針調用的（ip_rcv是在內核初始化時通過ip_init函數與func指針關聯的）。
      在ip_rcv函數中通過skb_share_check函數對skb進行拷貝，接下來調整IP層的data起始位置，最后通過ip_rcv_finish處理路由轉發(fā)還是繼續(xù)往上層傳遞。
      在ip_rcv_finish中也是對skb包進行一系列檢查，調用ip_route_input函數處理路由，設置此數據包的路由出口，接下來調用dst_input函數處理轉發(fā)還是向上傳。如果是轉發(fā)則調用ip_forward，如果是向上傳則調用ip_local_deliver。

      這是大概的包流程，寫出來和大家一起探討，互相進步。不一定對啊，僅供參考。

wuweiyoung

這個論壇的同志就是叼