* [net-next:master 2/17] drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1932:17: sparse: incorrect type in initializer (different base types)
From: kbuild test robot @ 2012-12-13 0:30 UTC (permalink / raw)
To: Rasesh Mody; +Cc: netdev
tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 520dfe3a3645257bf83660f672c47f8558f3d4c4
commit: 5216562a2ccd037d0eb85a2e8bbfd6315e3f1bb5 [2/17] bna: Tx and Rx Optimizations
sparse warnings:
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:283:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:299:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:299:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:299:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:315:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:315:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:315:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:317:21: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:317:21: expected unsigned short [unsigned] [usertype] handle
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:317:21: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:330:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:330:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:330:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:345:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:345:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:345:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:362:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:362:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:362:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:368:42: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:368:42: expected unsigned int [unsigned] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:368:42: got restricted __be32 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:385:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:385:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:385:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:400:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:400:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:400:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:402:19: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:402:19: expected unsigned short [unsigned] [usertype] size
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:402:19: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:417:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:417:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:417:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:422:33: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:422:33: expected unsigned int [unsigned] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:422:33: got restricted __be32 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:436:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:436:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:436:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:723:17: sparse: cast to restricted __be16
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:723:17: sparse: cast to restricted __be16
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:723:17: sparse: cast to restricted __be16
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:723:17: sparse: cast to restricted __be16
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1650:33: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1650:33: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1650:33: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1664:25: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1664:25: expected unsigned short [unsigned] [usertype] pages
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1664:25: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1664:25: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1664:25: expected unsigned short [unsigned] [usertype] page_sz
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1664:25: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1666:61: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1666:61: expected unsigned short [unsigned] [usertype] rx_buffer_size
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1666:61: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1672:25: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1672:25: expected unsigned short [unsigned] [usertype] pages
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1672:25: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1672:25: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1672:25: expected unsigned short [unsigned] [usertype] page_sz
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1672:25: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1676:61: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1676:61: expected unsigned short [unsigned] [usertype] rx_buffer_size
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1676:61: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1684:17: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1684:17: expected unsigned short [unsigned] [usertype] pages
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1684:17: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1684:17: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1684:17: expected unsigned short [unsigned] [usertype] page_sz
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1684:17: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1691:54: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1691:54: expected unsigned short [unsigned] [usertype] msix_index
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1691:54: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1702:44: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1702:44: expected unsigned int [unsigned] [usertype] coalescing_timeout
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1702:44: got restricted __be32 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1704:43: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1704:43: expected unsigned int [unsigned] [usertype] inter_pkt_timeout
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1704:43: got restricted __be32 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1406:1: sparse: symbol 'bna_rx_sm_stop_wait_entry' was not declared. Should it be static?
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1459:1: sparse: symbol 'bna_rx_sm_rxf_stop_wait_entry' was not declared. Should it be static?
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1492:1: sparse: symbol 'bna_rx_sm_started_entry' was not declared. Should it be static?
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1557:1: sparse: symbol 'bna_rx_sm_cleanup_wait_entry' was not declared. Should it be static?
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1562:1: sparse: symbol 'bna_rx_sm_cleanup_wait' was not declared. Should it be static?
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1741:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1741:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1741:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1926:9: sparse: cast to restricted __be32
+ drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1932:17: sparse: incorrect type in initializer (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1932:17: expected unsigned long long [unsigned] [usertype] tmp_addr
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1932:17: got restricted __be64 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1964:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1970:17: sparse: incorrect type in initializer (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1970:17: expected unsigned long long [unsigned] [usertype] tmp_addr
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:1970:17: got restricted __be64 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2185:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2185:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2185:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2185:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2185:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2185:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2189:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2189:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2189:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2189:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2189:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2189:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2194:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2194:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2194:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2194:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2194:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:2194:27: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3168:33: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3168:33: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3168:33: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3177:17: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3177:17: expected unsigned short [unsigned] [usertype] pages
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3177:17: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3177:17: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3177:17: expected unsigned short [unsigned] [usertype] page_sz
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3177:17: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3184:54: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3184:54: expected unsigned short [unsigned] [usertype] msix_index
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3184:54: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3194:44: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3194:44: expected unsigned int [unsigned] [usertype] coalescing_timeout
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3194:44: got restricted __be32 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3196:43: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3196:43: expected unsigned int [unsigned] [usertype] inter_pkt_timeout
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3196:43: got restricted __be32 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3201:33: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3201:33: expected unsigned short [unsigned] [usertype] vlan_id
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3201:33: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3217:29: sparse: incorrect type in assignment (different base types)
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3217:29: expected unsigned short [unsigned] [usertype] num_entries
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3217:29: got restricted __be16 [usertype] <noident>
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: cast to restricted __be32
+ drivers/net/ethernet/brocade/bna/bna_tx_rx.c:3260:9: sparse: too many warnings
vim +1932 drivers/net/ethernet/brocade/bna/bna_tx_rx.c
f3bd5173 Rasesh Mody 2011-08-08 1920 rxq->qpt.page_size = page_size;
f3bd5173 Rasesh Mody 2011-08-08 1921
f3bd5173 Rasesh Mody 2011-08-08 1922 rxq->rcb->sw_qpt = (void **) swqpt_mem->kva;
5216562a Rasesh Mody 2012-12-11 1923 rxq->rcb->sw_q = page_mem->kva;
5216562a Rasesh Mody 2012-12-11 1924
5216562a Rasesh Mody 2012-12-11 1925 kva = page_mem->kva;
5216562a Rasesh Mody 2012-12-11 @1926 BNA_GET_DMA_ADDR(&page_mem->dma, dma);
f3bd5173 Rasesh Mody 2011-08-08 1927
f3bd5173 Rasesh Mody 2011-08-08 1928 for (i = 0; i < rxq->qpt.page_count; i++) {
5216562a Rasesh Mody 2012-12-11 1929 rxq->rcb->sw_qpt[i] = kva;
5216562a Rasesh Mody 2012-12-11 1930 kva += PAGE_SIZE;
5216562a Rasesh Mody 2012-12-11 1931
5216562a Rasesh Mody 2012-12-11 @1932 BNA_SET_DMA_ADDR(dma, &bna_dma);
f3bd5173 Rasesh Mody 2011-08-08 1933 ((struct bna_dma_addr *)rxq->qpt.kv_qpt_ptr)[i].lsb =
5216562a Rasesh Mody 2012-12-11 1934 bna_dma.lsb;
f3bd5173 Rasesh Mody 2011-08-08 1935 ((struct bna_dma_addr *)rxq->qpt.kv_qpt_ptr)[i].msb =
---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu Intel Corporation
^ permalink raw reply
* [net-next:master 14/17] net/bridge/br_multicast.c:677:54: sparse: incorrect type in argument 3 (different address spaces)
From: kbuild test robot @ 2012-12-13 0:51 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev
tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 520dfe3a3645257bf83660f672c47f8558f3d4c4
commit: cfd567543590f71ca0af397437e2554f9756d750 [14/17] bridge: add support of adding and deleting mdb entries
sparse warnings:
net/bridge/br_multicast.c:635:17: sparse: incorrect type in assignment (different address spaces)
net/bridge/br_multicast.c:635:17: expected struct net_bridge_port_group [noderef] <asn:4>*next
net/bridge/br_multicast.c:635:17: got struct net_bridge_port_group *next
+ net/bridge/br_multicast.c:677:54: sparse: incorrect type in argument 3 (different address spaces)
net/bridge/br_multicast.c:677:54: expected struct net_bridge_port_group *next
net/bridge/br_multicast.c:677:54: got struct net_bridge_port_group [noderef] <asn:4>*<noident>
net/bridge/br_multicast.c:1175:48: sparse: restricted __be16 degrades to integer
net/bridge/br_multicast.c:1175:48: sparse: restricted __be16 degrades to integer
net/bridge/br_multicast.c:1175:48: sparse: restricted __be16 degrades to integer
net/bridge/br_multicast.c:1175:48: sparse: restricted __be16 degrades to integer
net/bridge/br_multicast.c:1175:48: sparse: restricted __be16 degrades to integer
net/bridge/br_multicast.c:1175:48: sparse: restricted __be16 degrades to integer
vim +677 net/bridge/br_multicast.c
cfd56754 Cong Wang 2012-12-11 629 p = kzalloc(sizeof(*p), GFP_ATOMIC);
cfd56754 Cong Wang 2012-12-11 630 if (unlikely(!p))
cfd56754 Cong Wang 2012-12-11 631 return NULL;
cfd56754 Cong Wang 2012-12-11 632
cfd56754 Cong Wang 2012-12-11 633 p->addr = *group;
cfd56754 Cong Wang 2012-12-11 634 p->port = port;
cfd56754 Cong Wang 2012-12-11 @635 p->next = next;
cfd56754 Cong Wang 2012-12-11 636 hlist_add_head(&p->mglist, &port->mglist);
cfd56754 Cong Wang 2012-12-11 637 setup_timer(&p->timer, br_multicast_port_group_expired,
cfd56754 Cong Wang 2012-12-11 638 (unsigned long)p);
cfd56754 Cong Wang 2012-12-11 639 return p;
cfd56754 Cong Wang 2012-12-11 640 }
cfd56754 Cong Wang 2012-12-11 641
eb1d1641 Herbert Xu 2010-02-27 642 static int br_multicast_add_group(struct net_bridge *br,
8ef2a9a5 YOSHIFUJI Hideaki 2010-04-18 643 struct net_bridge_port *port,
8ef2a9a5 YOSHIFUJI Hideaki 2010-04-18 644 struct br_ip *group)
eb1d1641 Herbert Xu 2010-02-27 645 {
eb1d1641 Herbert Xu 2010-02-27 646 struct net_bridge_mdb_entry *mp;
eb1d1641 Herbert Xu 2010-02-27 647 struct net_bridge_port_group *p;
e8051688 Eric Dumazet 2010-11-15 648 struct net_bridge_port_group __rcu **pp;
eb1d1641 Herbert Xu 2010-02-27 649 unsigned long now = jiffies;
eb1d1641 Herbert Xu 2010-02-27 650 int err;
eb1d1641 Herbert Xu 2010-02-27 651
eb1d1641 Herbert Xu 2010-02-27 652 spin_lock(&br->multicast_lock);
eb1d1641 Herbert Xu 2010-02-27 653 if (!netif_running(br->dev) ||
eb1d1641 Herbert Xu 2010-02-27 654 (port && port->state == BR_STATE_DISABLED))
eb1d1641 Herbert Xu 2010-02-27 655 goto out;
eb1d1641 Herbert Xu 2010-02-27 656
eb1d1641 Herbert Xu 2010-02-27 657 mp = br_multicast_new_group(br, port, group);
eb1d1641 Herbert Xu 2010-02-27 658 err = PTR_ERR(mp);
4c0833bc Tobias Klauser 2010-12-10 659 if (IS_ERR(mp))
eb1d1641 Herbert Xu 2010-02-27 660 goto err;
eb1d1641 Herbert Xu 2010-02-27 661
eb1d1641 Herbert Xu 2010-02-27 662 if (!port) {
8a870178 Herbert Xu 2011-02-12 663 mp->mglist = true;
eb1d1641 Herbert Xu 2010-02-27 664 mod_timer(&mp->timer, now + br->multicast_membership_interval);
eb1d1641 Herbert Xu 2010-02-27 665 goto out;
eb1d1641 Herbert Xu 2010-02-27 666 }
eb1d1641 Herbert Xu 2010-02-27 667
e8051688 Eric Dumazet 2010-11-15 668 for (pp = &mp->ports;
e8051688 Eric Dumazet 2010-11-15 669 (p = mlock_dereference(*pp, br)) != NULL;
e8051688 Eric Dumazet 2010-11-15 670 pp = &p->next) {
eb1d1641 Herbert Xu 2010-02-27 671 if (p->port == port)
eb1d1641 Herbert Xu 2010-02-27 672 goto found;
eb1d1641 Herbert Xu 2010-02-27 673 if ((unsigned long)p->port < (unsigned long)port)
eb1d1641 Herbert Xu 2010-02-27 674 break;
eb1d1641 Herbert Xu 2010-02-27 675 }
eb1d1641 Herbert Xu 2010-02-27 676
cfd56754 Cong Wang 2012-12-11 @677 p = br_multicast_new_port_group(port, group, *pp);
eb1d1641 Herbert Xu 2010-02-27 678 if (unlikely(!p))
eb1d1641 Herbert Xu 2010-02-27 679 goto err;
eb1d1641 Herbert Xu 2010-02-27 680 rcu_assign_pointer(*pp, p);
---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu Intel Corporation
^ permalink raw reply
* RFC: Launch Time Support
From: Ulf Samuelsson @ 2012-12-13 1:04 UTC (permalink / raw)
To: netdev
Hi, I am looking for some feedback on how to implement launchtime
in the kernel.
I.E: You define WHEN you want to send a packet,
and the driver will store the packet in a buffer and will send it out
on the net when the internal timestamp counter in the network controller
reaches the specified "launch time".
Some Ethernet controllers like the new Intel i210 support "launch time",
Support for launch time is desirable for any isochronous connection,
but I am currently interested in the NTP protocol to improve the timing.
Proposed Changes to the Kernel
===========================================================
The launchtime support will be dependent on CONFIG_NET_LAUNCHTIME
If this is not set, then the kernel functionality is not changed.
My current idea is to add a new bit to the "flags" field of
"socket.c:sendto"
#define MSG_LAUNCHTIME 0x?????
struct msghdr gets an additional launchtime field.
sendto will check if the flags parameter contains MSG_LAUNCHTIME.
If it does, then the first 64 bit longword of the packet (buff) contains
the launchtime.
The launchtime from the buffer is copied to the msghdr.launchtime field,
and the first 64 bits of the packet is then shaved off, before the address
is written to the msghdr.
Each network controller supporting launchtime needs to have an alternative
call to "send packet with launchtime" . This call adds the launchtime
parameter.
If launchtime is supported the exported "ops" includes the new call.
The UDP/IP packet send will check the MSG_LAUNCHTIME and
if set, it will check if the "send packet with launchtime" call
is available for the driver and if so call it, otherwise it will call
the normal send packet and thus ignore the launchtime.
Before launchtime is used, the application should send an ioctl
to the driver, making sure that launchtime is configured,
and only if the driver ACKs , the application will use launchtime.
(Possibly the "ops" field for "send packet with launchtime" should be
NULL until that ioctl is complete. Comments?)
To me, this seems to be transparent for all other network stacks
so protocols and drivers not supporting launchtime should still work.
As far as I know, drivers do not support launch time today.
The Intel igb driver does not in the latest version on the intel web site,
There are some defines headers in the latest version defining the registers
but so far, the code is not using it.
There is the linux_igb_avb project on sourceforge which allows use of
launch time for user space applications, but not as part of the kernel.
Maybe there is more work done somewhere else, but i am not aware
of this, so any links to such work is appreciated.
There are some FPGA based PCIe boards that support launchtime (Endace DAG)
using proprietary APIs.
Talked to some vendors providing TCP/IP offload engines for FPGA
and they do not support launchtime and liuke Endace use proprietary APIs
so they are only useable by custom programs. Normal networking interfaces
are not supported.
Comment on above is appreciated.
BACKGROUND
For those that do not know how the NTP protocol works:
===================================================
The client sends an UDP packet to the NTP server using port 123
The NTP client reads the current systime and puts that in the outgoing
packet.
There is a delay between the time the systime is read, and the time
the packet actually leaves the Ethernet controller adding jitter to the
NTP algorithm.
When the server receives the packet, it can be timestamped in H/W
and a CMSG is then created by the network stack containing that
timestamp for use by the server NTP daemon.
The server generates a reply, which needs to include the client
transmit time, the servers receive time, and the servers transmit time.
Again, the transmit time needs to be written into the NTP packet,
and then it needs to be processed through the network stack before it is
leaving the ethernet controller causing more jitter.
If launch time is supported, then the client NTP daemon would simply
read the systime, add a constant delay to create the transmit timestamp.
The delay needs to be sufficiently large to ensure that all processing
is done,
The server will do something similar adding a constant to the server
receive timestamp
to create the server transmit timestamp.
If both the client and the server uses H/W timestamping and launch time,
then the the jitter ideally is reduced to zero.
TRANSMIT TIMESTAMPING
========================
Support for TX timestamps in H/W is not really useful, since you need to
provide
the TX timestamp in the packet you measure on, so when you know the
timestamp
it is too late. Server to server NTP connections support sending that
timestamp
in a new packet, but there is no such support in client server
communication.
The i210 supports putting the timestamp inside the packet as it leaves the
Ethernet controller, but that means that you screw up the UDP checksum, so
the packet will be rejected by the receiving NTP daemon.
In addition, the i210 timestamp measures seconds and nanoseconds
which is incompatible with the NTP timestamp which uses seconds
and a 32 bit fraction of a second so that does not work either.
Best Regards
Ulf Samuelsson
eMagii.
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2012-12-13 2:15 UTC (permalink / raw)
To: David Miller
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List
In-Reply-To: <20121212.151116.143443755590581447.davem@davemloft.net>
On Wed, Dec 12, 2012 at 12:11 PM, David Miller <davem@davemloft.net> wrote:
>
> There is one merge conflict to resolve in net/sched/cls_cgroup.c,
> one commit changes the name of some members to "css_*" (this came
> from Tejun's tree) and another commit adds an "attach" method.
There's more than that. The ARM board mess is apparently now affecting
the networking merges too.
I fixed it up. Hopefully correctly.
Also, why does the new SHA1 hmac cookie support default to 'y'?
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2012-12-13 2:27 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <CA+55aFwzUgxQAze=mYbEx8b61V542tzm06Df=mR1BtYVbJy0mg@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 12 Dec 2012 18:15:04 -0800
> On Wed, Dec 12, 2012 at 12:11 PM, David Miller <davem@davemloft.net> wrote:
>>
>> There is one merge conflict to resolve in net/sched/cls_cgroup.c,
>> one commit changes the name of some members to "css_*" (this came
>> from Tejun's tree) and another commit adds an "attach" method.
>
> There's more than that. The ARM board mess is apparently now affecting
> the networking merges too.
>
> I fixed it up. Hopefully correctly.
>
> Also, why does the new SHA1 hmac cookie support default to 'y'?
There are two SCTP HMAC cookie algorithms, MD5 and SHA1.
What used to happen is that you had to choose one at build
time, and then you were stuck with that decision and it was
all that you could use.
Now, it's selectable at run time.
If there's anything you find particularly anti-social about
this, I'm sure we can adjust it.
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2012-12-13 2:37 UTC (permalink / raw)
To: David Miller
Cc: Andrew Morton, Network Development, Linux Kernel Mailing List
In-Reply-To: <20121212.212734.917363230032045212.davem@davemloft.net>
On Wed, Dec 12, 2012 at 6:27 PM, David Miller <davem@davemloft.net> wrote:
>
> There are two SCTP HMAC cookie algorithms, MD5 and SHA1.
>
> What used to happen is that you had to choose one at build
> time, and then you were stuck with that decision and it was
> all that you could use.
>
> Now, it's selectable at run time.
>
> If there's anything you find particularly anti-social about
> this, I'm sure we can adjust it.
So I'd suggest doing the same thing that the new thermal throttling
Kconfig does: start off by asking for the default algorithm, then ask
about the others.
The "choice" part selects the one that is default (so it never gets
asked about and is obviously compiled in), and the rest default to no
like we should.
See drivers/thermal/Kconfig for an example of this. I think we do it
in other places too, but that one happens to be new so I picked it as
an example.
The rule should be that we *never* default anything to 'yes', unless
it's old functionality that we always compiled in before too, and now
it got made conditional. So if you see a "default y" on new options,
you should basically consider it broken.
We're already bloating too much, we should not encourage people to
make things more bloated than necessary.
Btw, that Kconfig option has basically no useful help text either.
What's the point of repeating the question as a "help" message?
If people can't explain why anybody should enable it, it sure as hell
shouldn't default to 'y'. Maybe it shouldn't exist at all?
Linus
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2012-12-13 3:22 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel, nhorman, vyasevich
In-Reply-To: <CA+55aFxvHrNYB_J851XTkZ4EiwZ68Fb64DEU1JJmxPV-zB+9Vw@mail.gmail.com>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 12 Dec 2012 18:37:08 -0800
> On Wed, Dec 12, 2012 at 6:27 PM, David Miller <davem@davemloft.net> wrote:
>>
>> There are two SCTP HMAC cookie algorithms, MD5 and SHA1.
>>
>> What used to happen is that you had to choose one at build
>> time, and then you were stuck with that decision and it was
>> all that you could use.
>>
>> Now, it's selectable at run time.
>>
>> If there's anything you find particularly anti-social about
>> this, I'm sure we can adjust it.
>
> So I'd suggest doing the same thing that the new thermal throttling
> Kconfig does: start off by asking for the default algorithm, then ask
> about the others.
>
> The "choice" part selects the one that is default (so it never gets
> asked about and is obviously compiled in), and the rest default to no
> like we should.
>
> See drivers/thermal/Kconfig for an example of this. I think we do it
> in other places too, but that one happens to be new so I picked it as
> an example.
>
> The rule should be that we *never* default anything to 'yes', unless
> it's old functionality that we always compiled in before too, and now
> it got made conditional. So if you see a "default y" on new options,
> you should basically consider it broken.
>
> We're already bloating too much, we should not encourage people to
> make things more bloated than necessary.
>
> Btw, that Kconfig option has basically no useful help text either.
> What's the point of repeating the question as a "help" message?
>
> If people can't explain why anybody should enable it, it sure as hell
> shouldn't default to 'y'. Maybe it shouldn't exist at all?
Neil and Vlad, please take care of this.
Thanks.
^ permalink raw reply
* Re: [Query] TCP TFO Query
From: Yuchung Cheng @ 2012-12-13 3:49 UTC (permalink / raw)
To: Ketan Kulkarni; +Cc: netdev
In-Reply-To: <CAD6NSj4dMG3OC0mb4Qiq2eXTNwFBonkcnw=gRF5YAef-5yjeVQ@mail.gmail.com>
On Wed, Dec 12, 2012 at 10:17 AM, Ketan Kulkarni <ketkulka@gmail.com> wrote:
> Thanks Yuchung for your reply.
>
> My only concern is -If syn+data is sent by client and syn-ack only acks the
> ISN, then isnt this a sufficient indication that server now is not
> supporting the TFO? So for further connections to this server, instead of
> sending syn+data, only ask for cookie. (fall back to the state where it was
> all started) (Note that this condition is different from syn+data is dropped
> in the nw.)
>
> I agree with you in saying it doesn't lead to any performance penalty,
> however sending syn+data to a server seems a little odd when we know we have
> sufficient information to believe that it may not be accepted at first,
> retransmitted later. And otherwise we also have a way to fall back and
> re-attempt the TFO.
Your proposal sounds reasonable. We can change that. In addition,
maybe we can change the server to send SYN-ACK acking ISN only with a
cookie option, if the server prefers the client to still do SYN-data-cookie
next time for some reason. I will try prepare a rfc patch soon.
>
> Thoughts?
>
> Thanks,
> Ketan
>
> On Dec 12, 2012 3:34 AM, "Yuchung Cheng" <ycheng@google.com> wrote:
>>
>> Hi Ketan,
>>
>> On Tue, Dec 11, 2012 at 9:29 AM, Ketan Kulkarni <ketkulka@gmail.com>
>> wrote:
>> > Hi,
>> > I am testing tcp tfo behavior with httping client and polipo server on
>> > 3.7rc-8
>> >
>> > One observation from my TFO testing -If for a connection server sends
>> > a cookie to client, client always does TFO for subsequent connections.
>> > This is ok.
>> >
>> > If for some reason, server stops supporting TFO (either because server
>> > got restarted without TFO support (in my case) or because path changed
>> > and the nw node is dropping packet with unknown syn option or
>> > stripping the option), client does not clear up its cookie cache. It
>> > always sends data in syn and server never acks the syn-data and client
>> > retransmits.
>> >
>> > As per kernel code -if syn-data is not acked it is retransmitted
>> > immediately - with the assumption first syn was dropped (but the
>> > assumption server stopped supporting TFO might not have been
>> > considered)
>> >
>> > Will it be better to flush the cookie for this server and re-attempt
>> > the cookie "negotiation" on subsequent connection than to retransmit
>> > the data every time?
>> >
>> > Your thoughts?
>>
>> In our initial design the client actually removes the cookie of the
>> particular server
>> (!= flush the entire cache though). Later on we changed to the current
>> behavior because
>> it does not have a performance penalty. It falls back to regular
>> handshake:
>>
>> SYN/cookie/data -> SYN-ACK acking ISN -> ACK(data).
>>
>> It may happen frequently when a large server farms are upgrading to
>> support TFO.
>>
>> However there are always more options:
>> 1) Server can selectively instrument to delete old cookies by sending a
>> SYN-ACK
>> acking initial sequence with a null TFO option (== caching a null
>> cookie ==
>> removing the older one).
> In the case I mentioned, this might not help because server got restarted
> with TFO disabled so having this option can help cases when server
> understands/supports tfo and know when to delete the client side cookie. Or
> may be I am missing something!!!
>
>> 2) another client-side flag in sysctl_tcp_fastopen to remove cookie if
>> SYN-ACK
>> only acks the syn sequence.
> My view is to prefer keeping knobs as minimum as possible as otherwise imo
> we might put extra efforts on the user to know and understand why and what
> this flag is when he is simply interested in TFO.
>
>> 3) combination of 1 and 2.
>>
>> More ideas are welcome :)
>>
>> NOTE: I've checked in a patch so that syn-data not acked is not treated as
>> a
>> network-drop.
>> http://patchwork.ozlabs.org/patch/171978/
>>
>> Yuchung
>>
>> >
>> > Thanks,
>> > Ketan
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe netdev" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* GPF in skb_flow_dissect
From: Dave Jones @ 2012-12-13 4:16 UTC (permalink / raw)
To: netdev
Since todays net merge, I see this when I start openvpn..
general protection fault: 0000 [#1] PREEMPT SMP
Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables xfs iTCO_wdt iTCO_vendor_support snd_emu10k1 snd_util_mem snd_ac97_codec coretemp ac97_bus microcode snd_hwdep snd_seq pcspkr snd_pcm snd_page_alloc snd_timer lpc_ich i2c_i801 snd_rawmidi mfd_core snd_seq_device snd e1000e soundcore emu10k1_gp gameport i82975x_edac edac_core vhost_net tun macvtap macvlan kvm_intel kvm binfmt_misc nfsd auth_rpcgss nfs_acl lockd sunrpc btrfs libcrc32c zlib_deflate firewire_ohci sata_sil firewire_core crc_itu_t radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core floppy
CPU 0
Pid: 1381, comm: openvpn Not tainted 3.7.0+ #14 /D975XBX
RIP: 0010:[<ffffffff815b54a4>] [<ffffffff815b54a4>] skb_flow_dissect+0x314/0x3e0
RSP: 0018:ffff88007d0d9c48 EFLAGS: 00010206
RAX: 000000000000055d RBX: 6b6b6b6b6b6b6b4b RCX: 1471030a0180040a
RDX: 0000000000000005 RSI: 00000000ffffffe0 RDI: ffff8800ba83fa80
RBP: ffff88007d0d9cb8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000101 R12: ffff8800ba83fa80
R13: 0000000000000008 R14: ffff88007d0d9cc8 R15: ffff8800ba83fa80
FS: 00007f6637104800(0000) GS:ffff8800bf600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f563f5b01c4 CR3: 000000007d140000 CR4: 00000000000007f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process openvpn (pid: 1381, threadinfo ffff88007d0d8000, task ffff8800a540cd60)
Stack:
ffff8800ba83fa80 0000000000000296 0000000000000000 0000000000000000
ffff88007d0d9cc8 ffffffff815bcff4 ffff88007d0d9ce8 ffffffff815b1831
ffff88007d0d9ca8 00000000703f6364 ffff8800ba83fa80 0000000000000000
Call Trace:
[<ffffffff815bcff4>] ? netif_rx+0x114/0x4c0
[<ffffffff815b1831>] ? skb_copy_datagram_from_iovec+0x61/0x290
[<ffffffff815b672a>] __skb_get_rxhash+0x1a/0xd0
[<ffffffffa03b9538>] tun_get_user+0x418/0x810 [tun]
[<ffffffff8135f468>] ? delay_tsc+0x98/0xf0
[<ffffffff8109605c>] ? __rcu_read_unlock+0x5c/0xa0
[<ffffffffa03b9a41>] tun_chr_aio_write+0x81/0xb0 [tun]
[<ffffffff81145011>] ? __buffer_unlock_commit+0x41/0x50
[<ffffffff811db917>] do_sync_write+0xa7/0xe0
[<ffffffff811dc01f>] vfs_write+0xaf/0x190
[<ffffffff811dc375>] sys_write+0x55/0xa0
[<ffffffff81705540>] tracesys+0xdd/0xe2
Code: 41 8b 44 24 68 41 2b 44 24 6c 01 de 29 f0 83 f8 03 0f 8e a0 00 00 00 48 63 de 49 03 9c 24 e0 00 00 00 48 85 db 0f 84 72 fe ff ff <8b> 03 41 89 46 08 b8 01 00 00 00 e9 43 fd ff ff 0f 1f 40 00 48
RIP [<ffffffff815b54a4>] skb_flow_dissect+0x314/0x3e0
RSP <ffff88007d0d9c48>
---[ end trace 6d42c834c72c002e ]---
Faulting instruction is
0: 8b 03 mov (%rbx),%eax
rbx is slab poison (-20) so this looks like a use-after-free here...
flow->ports = *ports;
314: 8b 03 mov (%rbx),%eax
316: 41 89 46 08 mov %eax,0x8(%r14)
in the inlined skb_header_pointer in skb_flow_dissect
Dave
^ permalink raw reply
* remove noisy message from llcp_sock_sendmsg
From: Dave Jones @ 2012-12-13 4:11 UTC (permalink / raw)
To: netdev
This is easily triggerable when fuzz-testing as an unprivileged user.
We could rate-limit it, but given we don't print similar messages
for other protocols, I just removed it.
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/net/nfc/llcp/sock.c b/net/nfc/llcp/sock.c
index 0fa1e92..fea22eb 100644
--- a/net/nfc/llcp/sock.c
+++ b/net/nfc/llcp/sock.c
@@ -614,10 +614,6 @@ static int llcp_sock_sendmsg(struct kiocb *iocb, struct socket *sock,
if (msg->msg_namelen < sizeof(*addr)) {
release_sock(sk);
-
- pr_err("Invalid socket address length %d\n",
- msg->msg_namelen);
-
return -EINVAL;
}
^ permalink raw reply related
* Re: GPF in skb_flow_dissect
From: Eric Dumazet @ 2012-12-13 5:22 UTC (permalink / raw)
To: Dave Jones, Jason Wang, David Miller; +Cc: netdev
In-Reply-To: <20121213041644.GB1611@redhat.com>
From: Eric Dumazet <edumazet@google.com>
On Wed, 2012-12-12 at 23:16 -0500, Dave Jones wrote:
> Since todays net merge, I see this when I start openvpn..
>
> general protection fault: 0000 [#1] PREEMPT SMP
> Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables xfs iTCO_wdt iTCO_vendor_support snd_emu10k1 snd_util_mem snd_ac97_codec coretemp ac97_bus microcode snd_hwdep snd_seq pcspkr snd_pcm snd_page_alloc snd_timer lpc_ich i2c_i801 snd_rawmidi mfd_core snd_seq_device snd e1000e soundcore emu10k1_gp gameport i82975x_edac edac_core vhost_net tun macvtap macvlan kvm_intel kvm binfmt_misc nfsd auth_rpcgss nfs_acl lockd sunrpc btrfs libcrc32c zlib_deflate firewire_ohci sata_sil firewire_core crc_itu_t radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core floppy
> CPU 0
> Pid: 1381, comm: openvpn Not tainted 3.7.0+ #14 /D975XBX
> RIP: 0010:[<ffffffff815b54a4>] [<ffffffff815b54a4>] skb_flow_dissect+0x314/0x3e0
> RSP: 0018:ffff88007d0d9c48 EFLAGS: 00010206
> RAX: 000000000000055d RBX: 6b6b6b6b6b6b6b4b RCX: 1471030a0180040a
> RDX: 0000000000000005 RSI: 00000000ffffffe0 RDI: ffff8800ba83fa80
> RBP: ffff88007d0d9cb8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000101 R12: ffff8800ba83fa80
> R13: 0000000000000008 R14: ffff88007d0d9cc8 R15: ffff8800ba83fa80
> FS: 00007f6637104800(0000) GS:ffff8800bf600000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f563f5b01c4 CR3: 000000007d140000 CR4: 00000000000007f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process openvpn (pid: 1381, threadinfo ffff88007d0d8000, task ffff8800a540cd60)
> Stack:
> ffff8800ba83fa80 0000000000000296 0000000000000000 0000000000000000
> ffff88007d0d9cc8 ffffffff815bcff4 ffff88007d0d9ce8 ffffffff815b1831
> ffff88007d0d9ca8 00000000703f6364 ffff8800ba83fa80 0000000000000000
> Call Trace:
> [<ffffffff815bcff4>] ? netif_rx+0x114/0x4c0
> [<ffffffff815b1831>] ? skb_copy_datagram_from_iovec+0x61/0x290
> [<ffffffff815b672a>] __skb_get_rxhash+0x1a/0xd0
> [<ffffffffa03b9538>] tun_get_user+0x418/0x810 [tun]
> [<ffffffff8135f468>] ? delay_tsc+0x98/0xf0
> [<ffffffff8109605c>] ? __rcu_read_unlock+0x5c/0xa0
> [<ffffffffa03b9a41>] tun_chr_aio_write+0x81/0xb0 [tun]
> [<ffffffff81145011>] ? __buffer_unlock_commit+0x41/0x50
> [<ffffffff811db917>] do_sync_write+0xa7/0xe0
> [<ffffffff811dc01f>] vfs_write+0xaf/0x190
> [<ffffffff811dc375>] sys_write+0x55/0xa0
> [<ffffffff81705540>] tracesys+0xdd/0xe2
> Code: 41 8b 44 24 68 41 2b 44 24 6c 01 de 29 f0 83 f8 03 0f 8e a0 00 00 00 48 63 de 49 03 9c 24 e0 00 00 00 48 85 db 0f 84 72 fe ff ff <8b> 03 41 89 46 08 b8 01 00 00 00 e9 43 fd ff ff 0f 1f 40 00 48
> RIP [<ffffffff815b54a4>] skb_flow_dissect+0x314/0x3e0
> RSP <ffff88007d0d9c48>
> ---[ end trace 6d42c834c72c002e ]---
>
>
> Faulting instruction is
>
> 0: 8b 03 mov (%rbx),%eax
>
> rbx is slab poison (-20) so this looks like a use-after-free here...
>
> flow->ports = *ports;
> 314: 8b 03 mov (%rbx),%eax
> 316: 41 89 46 08 mov %eax,0x8(%r14)
>
> in the inlined skb_header_pointer in skb_flow_dissect
>
> Dave
>
Yes, commit 7694a3acc55a7 added this bug
Its illegal to use skb after call to netif_rx_ni(skb);
I would try following patch.
Thanks !
[PATCH] tuntap: dont use skb after netif_rx_ni(skb)
commit 96442e4242 (tuntap: choose the txq based on rxq) added
a use after free.
Cache rxhash in a temp variable before calling netif_rx_ni()
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 2ac2164..40b426e 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -297,13 +297,12 @@ static void tun_flow_cleanup(unsigned long data)
spin_unlock_bh(&tun->lock);
}
-static void tun_flow_update(struct tun_struct *tun, struct sk_buff *skb,
+static void tun_flow_update(struct tun_struct *tun, u32 rxhash,
u16 queue_index)
{
struct hlist_head *head;
struct tun_flow_entry *e;
unsigned long delay = tun->ageing_time;
- u32 rxhash = skb_get_rxhash(skb);
if (!rxhash)
return;
@@ -1010,6 +1009,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
int copylen;
bool zerocopy = false;
int err;
+ u32 rxhash;
if (!(tun->flags & TUN_NO_PI)) {
if ((len -= sizeof(pi)) > total_len)
@@ -1162,12 +1162,13 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY;
}
+ rxhash = skb_get_rxhash(skb);
netif_rx_ni(skb);
tun->dev->stats.rx_packets++;
tun->dev->stats.rx_bytes += len;
- tun_flow_update(tun, skb, tfile->queue_index);
+ tun_flow_update(tun, rxhash, tfile->queue_index);
return total_len;
}
^ permalink raw reply related
* Re: GPF in skb_flow_dissect
From: Jason Wang @ 2012-12-13 5:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Dave Jones, David Miller, netdev
In-Reply-To: <1355376177.12271.244.camel@edumazet-glaptop>
On 12/13/2012 01:22 PM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> On Wed, 2012-12-12 at 23:16 -0500, Dave Jones wrote:
>> Since todays net merge, I see this when I start openvpn..
>>
>> general protection fault: 0000 [#1] PREEMPT SMP
>> Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables xfs iTCO_wdt iTCO_vendor_support snd_emu10k1 snd_util_mem snd_ac97_codec coretemp ac97_bus microcode snd_hwdep snd_seq pcspkr snd_pcm snd_page_alloc snd_timer lpc_ich i2c_i801 snd_rawmidi mfd_core snd_seq_device snd e1000e soundcore emu10k1_gp gameport i82975x_edac edac_core vhost_net tun macvtap macvlan kvm_intel kvm binfmt_misc nfsd auth_rpcgss nfs_acl lockd sunrpc btrfs libcrc32c zlib_deflate firewire_ohci sata_sil firewire_core crc_itu_t radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core floppy
>> CPU 0
>> Pid: 1381, comm: openvpn Not tainted 3.7.0+ #14 /D975XBX
>> RIP: 0010:[<ffffffff815b54a4>] [<ffffffff815b54a4>] skb_flow_dissect+0x314/0x3e0
>> RSP: 0018:ffff88007d0d9c48 EFLAGS: 00010206
>> RAX: 000000000000055d RBX: 6b6b6b6b6b6b6b4b RCX: 1471030a0180040a
>> RDX: 0000000000000005 RSI: 00000000ffffffe0 RDI: ffff8800ba83fa80
>> RBP: ffff88007d0d9cb8 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000101 R12: ffff8800ba83fa80
>> R13: 0000000000000008 R14: ffff88007d0d9cc8 R15: ffff8800ba83fa80
>> FS: 00007f6637104800(0000) GS:ffff8800bf600000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00007f563f5b01c4 CR3: 000000007d140000 CR4: 00000000000007f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process openvpn (pid: 1381, threadinfo ffff88007d0d8000, task ffff8800a540cd60)
>> Stack:
>> ffff8800ba83fa80 0000000000000296 0000000000000000 0000000000000000
>> ffff88007d0d9cc8 ffffffff815bcff4 ffff88007d0d9ce8 ffffffff815b1831
>> ffff88007d0d9ca8 00000000703f6364 ffff8800ba83fa80 0000000000000000
>> Call Trace:
>> [<ffffffff815bcff4>] ? netif_rx+0x114/0x4c0
>> [<ffffffff815b1831>] ? skb_copy_datagram_from_iovec+0x61/0x290
>> [<ffffffff815b672a>] __skb_get_rxhash+0x1a/0xd0
>> [<ffffffffa03b9538>] tun_get_user+0x418/0x810 [tun]
>> [<ffffffff8135f468>] ? delay_tsc+0x98/0xf0
>> [<ffffffff8109605c>] ? __rcu_read_unlock+0x5c/0xa0
>> [<ffffffffa03b9a41>] tun_chr_aio_write+0x81/0xb0 [tun]
>> [<ffffffff81145011>] ? __buffer_unlock_commit+0x41/0x50
>> [<ffffffff811db917>] do_sync_write+0xa7/0xe0
>> [<ffffffff811dc01f>] vfs_write+0xaf/0x190
>> [<ffffffff811dc375>] sys_write+0x55/0xa0
>> [<ffffffff81705540>] tracesys+0xdd/0xe2
>> Code: 41 8b 44 24 68 41 2b 44 24 6c 01 de 29 f0 83 f8 03 0f 8e a0 00 00 00 48 63 de 49 03 9c 24 e0 00 00 00 48 85 db 0f 84 72 fe ff ff <8b> 03 41 89 46 08 b8 01 00 00 00 e9 43 fd ff ff 0f 1f 40 00 48
>> RIP [<ffffffff815b54a4>] skb_flow_dissect+0x314/0x3e0
>> RSP <ffff88007d0d9c48>
>> ---[ end trace 6d42c834c72c002e ]---
>>
>>
>> Faulting instruction is
>>
>> 0: 8b 03 mov (%rbx),%eax
>>
>> rbx is slab poison (-20) so this looks like a use-after-free here...
>>
>> flow->ports = *ports;
>> 314: 8b 03 mov (%rbx),%eax
>> 316: 41 89 46 08 mov %eax,0x8(%r14)
>>
>> in the inlined skb_header_pointer in skb_flow_dissect
>>
>> Dave
>>
> Yes, commit 7694a3acc55a7 added this bug
>
> Its illegal to use skb after call to netif_rx_ni(skb);
>
> I would try following patch.
>
> Thanks !
>
> [PATCH] tuntap: dont use skb after netif_rx_ni(skb)
>
> commit 96442e4242 (tuntap: choose the txq based on rxq) added
> a use after free.
>
> Cache rxhash in a temp variable before calling netif_rx_ni()
>
> Reported-by: Dave Jones <davej@redhat.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Jason Wang <jasowang@redhat.com>
> ---
> drivers/net/tun.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
Acked-by: Jason Wang <jasowang@redhat.com>
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 2ac2164..40b426e 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -297,13 +297,12 @@ static void tun_flow_cleanup(unsigned long data)
> spin_unlock_bh(&tun->lock);
> }
>
> -static void tun_flow_update(struct tun_struct *tun, struct sk_buff *skb,
> +static void tun_flow_update(struct tun_struct *tun, u32 rxhash,
> u16 queue_index)
> {
> struct hlist_head *head;
> struct tun_flow_entry *e;
> unsigned long delay = tun->ageing_time;
> - u32 rxhash = skb_get_rxhash(skb);
>
> if (!rxhash)
> return;
> @@ -1010,6 +1009,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
> int copylen;
> bool zerocopy = false;
> int err;
> + u32 rxhash;
>
> if (!(tun->flags & TUN_NO_PI)) {
> if ((len -= sizeof(pi)) > total_len)
> @@ -1162,12 +1162,13 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile,
> skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY;
> }
>
> + rxhash = skb_get_rxhash(skb);
> netif_rx_ni(skb);
>
> tun->dev->stats.rx_packets++;
> tun->dev->stats.rx_bytes += len;
>
> - tun_flow_update(tun, skb, tfile->queue_index);
> + tun_flow_update(tun, rxhash, tfile->queue_index);
> return total_len;
> }
>
>
>
^ permalink raw reply
* Re: [net-next:master 14/17] net/bridge/br_mdb.c:330 br_mdb_add_group() error: potential null dereference 'mp'. (br_multicast_new_group returns null)
From: Cong Wang @ 2012-12-13 7:15 UTC (permalink / raw)
To: kbuild test robot; +Cc: netdev
In-Reply-To: <50c8d94d.VSxb5ulWJHo9Ahhi%fengguang.wu@intel.com>
On Thu, 2012-12-13 at 03:21 +0800, kbuild test robot wrote:
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
> head: 520dfe3a3645257bf83660f672c47f8558f3d4c4
> commit: cfd567543590f71ca0af397437e2554f9756d750 [14/17] bridge: add support of adding and deleting mdb entries
>
>
> smatch warnings:
>
> + net/bridge/br_mdb.c:330 br_mdb_add_group() error: potential null dereference 'mp'. (br_multicast_new_group returns null)
br_multicast_new_group() seems impossible to return NULL, it either
returns a valid pointer (non-NULL) or some errno pointer.
OTOH, br_multicast_add_group() doesn't check for NULL either.
^ permalink raw reply
* Re: [RFC] net : add tx timestamp to packet mmap.
From: Paul Chavent @ 2012-12-13 7:13 UTC (permalink / raw)
To: David Miller; +Cc: edumazet, daniel.borkmann, xemul, ebiederm, netdev
In-Reply-To: <20121212.142327.2290797438095968580.davem@davemloft.net>
After a sendmsg, we have to call recvmsg on the ERRQUEUE to get
timestamp. I find that unfortunate indeed...
So this patch fix the tx timestamping (that take place in sendmsg), in
order to be able to get timestamp (via recvmsg).
This seems suboptimal to me, that why i also ask if it wouldn't be
possible to put the timestamp in the ring buffer frame before give it
back to user.
Thanks for your reading.
On 12/12/2012 08:23 PM, David Miller wrote:
>
> You're changing the code that handles sendmsg() and then wondering why
> a recvmsg() call doesn't provide a timestamp.
>
^ permalink raw reply
* Re: [PATCH v2] netfilter: nf_nat: Also handle non-ESTABLISHED routing changes in MASQUERADE
From: Jozsef Kadlecsik @ 2012-12-13 8:19 UTC (permalink / raw)
To: Andrew Collins; +Cc: netfilter-devel, netdev
In-Reply-To: <1355358229-25167-1-git-send-email-bsderandrew@gmail.com>
On Wed, 12 Dec 2012, Andrew Collins wrote:
> The MASQUERADE target now handles routing changes which affect
> the output interface of a connection, but only for ESTABLISHED
> connections. It is also possible for NEW connections which
> already have a conntrack entry to be affected by routing changes.
>
> This adds a check to drop entries in the NEW+conntrack state
> when the oif has changed.
>
> Signed-off-by: Andrew Collins <bsderandrew@gmail.com>
Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* [RFC PATCH] xfrm: avoid to send/receive the exceeding hard lifetime data
From: roy.qing.li @ 2012-12-13 8:25 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
If setkey sets both bh and bs as 1024, and the total send and receive package
size is 1024, then if next package size is too large, this package should be
discard.
Example, first package size is 1000, send success, then the second package
is 500, 1000+500 is larger than 1024, so the second package should be discard.
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/xfrm/xfrm_input.c | 6 +++---
net/xfrm/xfrm_output.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index ab2bb42..d0de8f3 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -178,6 +178,9 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
goto drop_unlock;
}
+ x->curlft.bytes += skb->len;
+ x->curlft.packets++;
+
if (xfrm_state_check_expire(x)) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEEXPIRED);
goto drop_unlock;
@@ -219,9 +222,6 @@ resume:
x->repl->advance(x, seq);
- x->curlft.bytes += skb->len;
- x->curlft.packets++;
-
spin_unlock(&x->lock);
XFRM_MODE_SKB_CB(skb)->protocol = nexthdr;
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 95a338c..0f38cb2 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -61,6 +61,9 @@ static int xfrm_output_one(struct sk_buff *skb, int err)
}
spin_lock_bh(&x->lock);
+
+ x->curlft.bytes += skb->len;
+ x->curlft.packets++;
err = xfrm_state_check_expire(x);
if (err) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTSTATEEXPIRED);
@@ -73,9 +76,6 @@ static int xfrm_output_one(struct sk_buff *skb, int err)
goto error;
}
- x->curlft.bytes += skb->len;
- x->curlft.packets++;
-
spin_unlock_bh(&x->lock);
skb_dst_force(skb);
--
1.7.5.4
^ permalink raw reply related
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Daniel Borkmann @ 2012-12-13 8:35 UTC (permalink / raw)
To: ani; +Cc: Michael Richardson, netdev, tcpdump-workers, Francesco Ruggeri
In-Reply-To: <alpine.OSX.2.00.1212121205040.78903@animac.local>
On 12/12/2012 10:53 PM, Ani Sinha wrote:
>> unsigned int netdev_8021q_inskb = 1;
>>
>> ...
>> {
>> .ctl_name = NET_CORE_8021q_INSKB,
>> .procname = "netdev_8021q_inskb",
>> .data = &netdev_8021q_inskb,
>> .maxlen = sizeof(int),
>> .mode = 0444,
>> .proc_handler = proc_dointvec
>> },
>>
>> would seem to do it to me.
>> Then pcap can fopen("/proc/sys/net/core/netdev_8021q_inskb") and if it
>> finds it, and it is >0, then do the cmsg thing.
>>
>
> Does this work? This is just an experimental patch and by no means final.
> I just want to have an idea what everyone thought about it. Once we debate
> and discusss, I can cook up a final patch that would be worth commiting.
>
> Also instead of having this /proc interface, we can perhaps check for a
> specific
> kernel version that :
>
> (a) has the vlan tag info in the skb metadata (as opposed to in the packet
> itself)
> (b) has the following patch that adds the capability to generate a filter
> based on the tag value :
>
> commit f3335031b9452baebfe49b8b5e55d3fe0c4677d1
> Author: Eric Dumazet <edumazet@google.com>
> Date: Sat Oct 27 02:26:17 2012 +0000
>
> net: filter: add vlan tag access
>
> WE need both of the above two things for the userland to generate a filter
> code that compares vlan tag values in the skb metadata. For kernels that
> has the vlan tag in
> the skb metadata but does not have the above commit (b), there is nothing
> that can be done. For older kernels that had the vlan tag info in the
> packet itself, the filter code can be generated differently to look at
> specific offsets within the packet (something that libpcap does
> currently).
>
> We have already ruled out the idea of generating a filter and trying to
> load and see if that fails (see previous emails on this thread).
>
> Hope this makes sense.
I think it doesn't. Because then you are obviously considering adding one
procfs file into /proc/sys/net/core/ *for each* feature that is added into
the ancillary ops which cannot be the right way ...
> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index c45eabc..91e2ba3 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -36,6 +36,7 @@ static inline unsigned int sk_filter_len(const struct sk_filter *fp)
> return fp->len * sizeof(struct sock_filter) + sizeof(*fp);
> }
>
> +extern bool sysctl_8021q_inskb;
> extern int sk_filter(struct sock *sk, struct sk_buff *skb);
> extern unsigned int sk_run_filter(const struct sk_buff *skb,
> const struct sock_filter *filter);
> diff --git a/net/core/filter.c b/net/core/filter.c
> index c23543c..4f5a657 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -41,6 +41,8 @@
> #include <linux/seccomp.h>
> #include <linux/if_vlan.h>
>
> +bool sysctl_8021q_inskb = 1;
> +
> /* No hurry in this branch
> *
> * Exported for the bpf jit load helper.
> diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
> index d1b0804..f9a3700 100644
> --- a/net/core/sysctl_net_core.c
> +++ b/net/core/sysctl_net_core.c
> @@ -15,6 +15,7 @@
> #include <linux/init.h>
> #include <linux/slab.h>
> #include <linux/kmemleak.h>
> +#include <linux/filter.h>
>
> #include <net/ip.h>
> #include <net/sock.h>
> @@ -189,6 +190,13 @@ static struct ctl_table net_core_table[] = {
> .mode = 0644,
> .proc_handler = proc_dointvec
> },
> + {
> + .procname = "8021q_inskb",
> + .data = &sysctl_8021q_inskb,
> + .maxlen = sizeof(bool),
> + .mode = 0444,
> + .proc_handler = proc_dointvec
> + },
> { }
> };
^ permalink raw reply
* [PATCH] xfrm: do not check x->km.state
From: roy.qing.li @ 2012-12-13 9:06 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
do not check x->km.state, it will be checked by succedent
xfrm_state_check_expire()
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/ipv6/xfrm6_input.c | 1 -
net/xfrm/xfrm_input.c | 4 ----
2 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
index f8c3cf8..de4babd 100644
--- a/net/ipv6/xfrm6_input.c
+++ b/net/ipv6/xfrm6_input.c
@@ -108,7 +108,6 @@ int xfrm6_input_addr(struct sk_buff *skb, xfrm_address_t *daddr,
spin_lock(&x->lock);
if ((!i || (x->props.flags & XFRM_STATE_WILDRECV)) &&
- likely(x->km.state == XFRM_STATE_VALID) &&
!xfrm_state_check_expire(x)) {
spin_unlock(&x->lock);
if (x->type->input(x, skb) > 0) {
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index ab2bb42..a8fbb09 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -163,10 +163,6 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
skb->sp->xvec[skb->sp->len++] = x;
spin_lock(&x->lock);
- if (unlikely(x->km.state != XFRM_STATE_VALID)) {
- XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEINVALID);
- goto drop_unlock;
- }
if ((x->encap ? x->encap->encap_type : 0) != encap_type) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEMISMATCH);
--
1.7.5.4
^ permalink raw reply related
* [PATCH iproute2 v2] ip: use rtnelink to manage mroute
From: Nicolas Dichtel @ 2012-12-13 9:16 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <20121212102617.0a3249e4@nehalam.linuxnetplumber.net>
mroute was using /proc/net/ip_mr_[vif|cache] to display mroute entries. Hence,
only RT_TABLE_DEFAULT was displayed and only IPv4.
With rtnetlink, it is possible to display all tables for IPv4 and IPv6. The output
format is kept. Also, like before the patch, statistics are displayed when user specify
the '-s' argument.
The patch also adds the support of 'ip monitor mroute', which is now possible.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
v2: fix compilation warnings on 64bits arch
ip/ip_common.h | 3 +
ip/ipmonitor.c | 35 ++++++-
ip/ipmroute.c | 297 ++++++++++++++++++++++++++++++++++-----------------------
3 files changed, 214 insertions(+), 121 deletions(-)
create mode 100644 ip/ipmonitor.
diff --git a/ip/ip_common.h b/ip/ip_common.h
index a394669..de56810 100644
--- a/ip/ip_common.h
+++ b/ip/ip_common.h
@@ -16,11 +16,14 @@ extern int ipaddr_list_link(int argc, char **argv);
extern int iproute_monitor(int argc, char **argv);
extern void iplink_usage(void) __attribute__((noreturn));
extern void iproute_reset_filter(void);
+extern void ipmroute_reset_filter(void);
extern void ipaddr_reset_filter(int);
extern void ipneigh_reset_filter(void);
extern void ipntable_reset_filter(void);
extern int print_route(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg);
+extern int print_mroute(const struct sockaddr_nl *who,
+ struct nlmsghdr *n, void *arg);
extern int print_prefix(const struct sockaddr_nl *who,
struct nlmsghdr *n, void *arg);
extern int print_rule(const struct sockaddr_nl *who,
diff --git a/ip/ipmonitor. b/ip/ipmonitor.
new file mode 100644
index 0000000..e69de29
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index d971623..09a339c 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -43,10 +43,26 @@ int accept_msg(const struct sockaddr_nl *who,
print_timestamp(fp);
if (n->nlmsg_type == RTM_NEWROUTE || n->nlmsg_type == RTM_DELROUTE) {
- if (prefix_banner)
- fprintf(fp, "[ROUTE]");
- print_route(who, n, arg);
- return 0;
+ struct rtmsg *r = NLMSG_DATA(n);
+ int len = n->nlmsg_len - NLMSG_LENGTH(sizeof(*r));
+
+ if (len < 0) {
+ fprintf(stderr, "BUG: wrong nlmsg len %d\n", len);
+ return -1;
+ }
+
+ if (r->rtm_family == RTNL_FAMILY_IPMR ||
+ r->rtm_family == RTNL_FAMILY_IP6MR) {
+ if (prefix_banner)
+ fprintf(fp, "[MROUTE]");
+ print_mroute(who, n, arg);
+ return 0;
+ } else {
+ if (prefix_banner)
+ fprintf(fp, "[ROUTE]");
+ print_route(who, n, arg);
+ return 0;
+ }
}
if (n->nlmsg_type == RTM_NEWLINK || n->nlmsg_type == RTM_DELLINK) {
ll_remember_index(who, n, NULL);
@@ -123,6 +139,7 @@ int do_ipmonitor(int argc, char **argv)
int llink=0;
int laddr=0;
int lroute=0;
+ int lmroute=0;
int lprefix=0;
int lneigh=0;
int lnetconf=0;
@@ -130,6 +147,7 @@ int do_ipmonitor(int argc, char **argv)
rtnl_close(&rth);
ipaddr_reset_filter(1);
iproute_reset_filter();
+ ipmroute_reset_filter();
ipneigh_reset_filter();
while (argc > 0) {
@@ -145,6 +163,9 @@ int do_ipmonitor(int argc, char **argv)
} else if (matches(*argv, "route") == 0) {
lroute=1;
groups = 0;
+ } else if (matches(*argv, "mroute") == 0) {
+ lmroute=1;
+ groups = 0;
} else if (matches(*argv, "prefix") == 0) {
lprefix=1;
groups = 0;
@@ -180,6 +201,12 @@ int do_ipmonitor(int argc, char **argv)
if (!preferred_family || preferred_family == AF_INET6)
groups |= nl_mgrp(RTNLGRP_IPV6_ROUTE);
}
+ if (lmroute) {
+ if (!preferred_family || preferred_family == AF_INET)
+ groups |= nl_mgrp(RTNLGRP_IPV4_MROUTE);
+ if (!preferred_family || preferred_family == AF_INET6)
+ groups |= nl_mgrp(RTNLGRP_IPV6_MROUTE);
+ }
if (lprefix) {
if (!preferred_family || preferred_family == AF_INET6)
groups |= nl_mgrp(RTNLGRP_IPV6_PREFIX);
diff --git a/ip/ipmroute.c b/ip/ipmroute.c
index 945727d..defcfc5 100644
--- a/ip/ipmroute.c
+++ b/ip/ipmroute.c
@@ -15,6 +15,7 @@
#include <unistd.h>
#include <syslog.h>
#include <fcntl.h>
+#include <inttypes.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <netinet/in.h>
@@ -26,167 +27,229 @@
#include <linux/if_arp.h>
#include <linux/sockios.h>
+#include <rt_names.h>
#include "utils.h"
-
-char filter_dev[16];
-int filter_family;
+#include "ip_common.h"
static void usage(void) __attribute__((noreturn));
static void usage(void)
{
- fprintf(stderr, "Usage: ip mroute show [ PREFIX ] [ from PREFIX ] [ iif DEVICE ]\n");
+ fprintf(stderr, "Usage: ip mroute show [ [ to ] PREFIX ] [ from PREFIX ] [ iif DEVICE ]\n");
#if 0
fprintf(stderr, "Usage: ip mroute [ add | del ] DESTINATION from SOURCE [ iif DEVICE ] [ oif DEVICE ]\n");
#endif
exit(-1);
}
-static char *viftable[32];
-
struct rtfilter
{
+ int tb;
+ int af;
+ int iif;
inet_prefix mdst;
inet_prefix msrc;
} filter;
-static void read_viftable(void)
+int print_mroute(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
{
- char buf[256];
- FILE *fp = fopen("/proc/net/ip_mr_vif", "r");
-
- if (!fp)
- return;
-
- if (!fgets(buf, sizeof(buf), fp)) {
- fclose(fp);
- return;
+ FILE *fp = (FILE*)arg;
+ struct rtmsg *r = NLMSG_DATA(n);
+ int len = n->nlmsg_len;
+ struct rtattr * tb[RTA_MAX+1];
+ char abuf[256];
+ char obuf[256];
+ SPRINT_BUF(b1);
+ __u32 table;
+ int iif = 0;
+ int family;
+
+ if ((n->nlmsg_type != RTM_NEWROUTE &&
+ n->nlmsg_type != RTM_DELROUTE) ||
+ !(n->nlmsg_flags & NLM_F_MULTI)) {
+ fprintf(stderr, "Not a multicast route: %08x %08x %08x\n",
+ n->nlmsg_len, n->nlmsg_type, n->nlmsg_flags);
+ return 0;
}
- while (fgets(buf, sizeof(buf), fp)) {
- int vifi;
- char dev[256];
-
- if (sscanf(buf, "%d%s", &vifi, dev) < 2)
- continue;
-
- if (vifi<0 || vifi>31)
- continue;
-
- viftable[vifi] = strdup(dev);
+ len -= NLMSG_LENGTH(sizeof(*r));
+ if (len < 0) {
+ fprintf(stderr, "BUG: wrong nlmsg len %d\n", len);
+ return -1;
}
- fclose(fp);
-}
-
-static void read_mroute_list(FILE *ofp)
-{
- char buf[256];
- FILE *fp = fopen("/proc/net/ip_mr_cache", "r");
-
- if (!fp)
- return;
-
- if (!fgets(buf, sizeof(buf), fp)) {
- fclose(fp);
- return;
+ if (r->rtm_type != RTN_MULTICAST) {
+ fprintf(stderr, "Not a multicast route (type: %s)\n",
+ rtnl_rtntype_n2a(r->rtm_type, b1, sizeof(b1)));
+ return 0;
}
- while (fgets(buf, sizeof(buf), fp)) {
- inet_prefix maddr, msrc;
- unsigned pkts, b, w;
- int vifi;
- char oiflist[256];
- char sbuf[256];
- char mbuf[256];
- char obuf[256];
-
- oiflist[0] = 0;
- if (sscanf(buf, "%x%x%d%u%u%u %[^\n]",
- maddr.data, msrc.data, &vifi,
- &pkts, &b, &w, oiflist) < 6)
- continue;
-
- if (vifi!=-1 && (vifi < 0 || vifi>31))
- continue;
-
- if (filter_dev[0] && (vifi<0 || strcmp(filter_dev, viftable[vifi])))
- continue;
- if (filter.mdst.family && inet_addr_match(&maddr, &filter.mdst, filter.mdst.bitlen))
- continue;
- if (filter.msrc.family && inet_addr_match(&msrc, &filter.msrc, filter.msrc.bitlen))
- continue;
-
- snprintf(obuf, sizeof(obuf), "(%s, %s)",
- format_host(AF_INET, 4, &msrc.data[0], sbuf, sizeof(sbuf)),
- format_host(AF_INET, 4, &maddr.data[0], mbuf, sizeof(mbuf)));
-
- fprintf(ofp, "%-32s Iif: ", obuf);
-
- if (vifi == -1)
- fprintf(ofp, "unresolved ");
- else
- fprintf(ofp, "%-10s ", viftable[vifi]);
-
- if (oiflist[0]) {
- char *next = NULL;
- char *p = oiflist;
- int ovifi, ottl;
-
- fprintf(ofp, "Oifs: ");
-
- while (p) {
- next = strchr(p, ' ');
- if (next) {
- *next = 0;
- next++;
- }
- if (sscanf(p, "%d:%d", &ovifi, &ottl)<2) {
- p = next;
- continue;
- }
- p = next;
-
- fprintf(ofp, "%s", viftable[ovifi]);
- if (ottl>1)
- fprintf(ofp, "(ttl %d) ", ovifi);
- else
- fprintf(ofp, " ");
+ parse_rtattr(tb, RTA_MAX, RTM_RTA(r), len);
+ table = rtm_get_table(r, tb);
+
+ if (filter.tb > 0 && filter.tb != table)
+ return 0;
+
+ if (tb[RTA_IIF])
+ iif = *(int*)RTA_DATA(tb[RTA_IIF]);
+ if (filter.iif && filter.iif != iif)
+ return 0;
+
+ if (filter.af && filter.af != r->rtm_family)
+ return 0;
+
+ if (tb[RTA_DST] &&
+ filter.mdst.bitlen > 0 &&
+ inet_addr_match(RTA_DATA(tb[RTA_DST]), &filter.mdst, filter.mdst.bitlen))
+ return 0;
+
+ if (tb[RTA_SRC] &&
+ filter.msrc.bitlen > 0 &&
+ inet_addr_match(RTA_DATA(tb[RTA_SRC]), &filter.msrc, filter.msrc.bitlen))
+ return 0;
+
+ family = r->rtm_family == RTNL_FAMILY_IPMR ? AF_INET : AF_INET6;
+
+ if (n->nlmsg_type == RTM_DELROUTE)
+ fprintf(fp, "Deleted ");
+
+ if (tb[RTA_SRC])
+ len = snprintf(obuf, sizeof(obuf),
+ "(%s, ", rt_addr_n2a(family,
+ RTA_PAYLOAD(tb[RTA_SRC]),
+ RTA_DATA(tb[RTA_SRC]),
+ abuf, sizeof(abuf)));
+ else
+ len = sprintf(obuf, "(unknown, ");
+ if (tb[RTA_DST])
+ snprintf(obuf + len, sizeof(obuf) - len,
+ "%s)", rt_addr_n2a(family, RTA_PAYLOAD(tb[RTA_DST]),
+ RTA_DATA(tb[RTA_DST]),
+ abuf, sizeof(abuf)));
+ else
+ snprintf(obuf + len, sizeof(obuf) - len, "unknown) ");
+
+ fprintf(fp, "%-32s Iif: ", obuf);
+ if (iif)
+ fprintf(fp, "%-10s ", ll_index_to_name(iif));
+ else
+ fprintf(fp, "unresolved ");
+
+ if (tb[RTA_MULTIPATH]) {
+ struct rtnexthop *nh = RTA_DATA(tb[RTA_MULTIPATH]);
+ int first = 1;
+
+ len = RTA_PAYLOAD(tb[RTA_MULTIPATH]);
+
+ for (;;) {
+ if (len < sizeof(*nh))
+ break;
+ if (nh->rtnh_len > len)
+ break;
+
+ if (first) {
+ fprintf(fp, "Oifs: ");
+ first = 0;
}
+ fprintf(fp, "%s", ll_index_to_name(nh->rtnh_ifindex));
+ if (nh->rtnh_hops > 1)
+ fprintf(fp, "(ttl %d) ", nh->rtnh_hops);
+ else
+ fprintf(fp, " ");
+ len -= NLMSG_ALIGN(nh->rtnh_len);
+ nh = RTNH_NEXT(nh);
}
-
- if (show_stats && b) {
- fprintf(ofp, "%s %u packets, %u bytes", _SL_, pkts, b);
- if (w)
- fprintf(ofp, ", %u arrived on wrong iif.", w);
- }
- fprintf(ofp, "\n");
}
- fclose(fp);
+ if (show_stats && tb[RTA_MFC_STATS]) {
+ struct rta_mfc_stats *mfcs = RTA_DATA(tb[RTA_MFC_STATS]);
+
+ fprintf(fp, "%s %"PRIu64" packets, %"PRIu64" bytes", _SL_,
+ (uint64_t)mfcs->mfcs_packets,
+ (uint64_t)mfcs->mfcs_bytes);
+ if (mfcs->mfcs_wrong_if)
+ fprintf(fp, ", %"PRIu64" arrived on wrong iif.",
+ (uint64_t)mfcs->mfcs_wrong_if);
+ }
+ fprintf(fp, "\n");
+ fflush(fp);
+ return 0;
}
+void ipmroute_reset_filter(void)
+{
+ memset(&filter, 0, sizeof(filter));
+ filter.mdst.bitlen = -1;
+ filter.msrc.bitlen = -1;
+}
static int mroute_list(int argc, char **argv)
{
+ char *id = NULL;
+ int family;
+
+ ipmroute_reset_filter();
+ if (preferred_family == AF_UNSPEC)
+ family = AF_INET;
+ else
+ family = AF_INET6;
+ if (family == AF_INET) {
+ filter.af = RTNL_FAMILY_IPMR;
+ filter.tb = RT_TABLE_DEFAULT; /* for backward compatibility */
+ } else
+ filter.af = RTNL_FAMILY_IP6MR;
+
while (argc > 0) {
- if (strcmp(*argv, "iif") == 0) {
+ if (matches(*argv, "table") == 0) {
+ __u32 tid;
NEXT_ARG();
- strncpy(filter_dev, *argv, sizeof(filter_dev)-1);
+ if (rtnl_rttable_a2n(&tid, *argv)) {
+ if (strcmp(*argv, "all") == 0) {
+ filter.tb = 0;
+ } else if (strcmp(*argv, "help") == 0) {
+ usage();
+ } else {
+ invarg("table id value is invalid\n", *argv);
+ }
+ } else
+ filter.tb = tid;
+ } else if (strcmp(*argv, "iif") == 0) {
+ NEXT_ARG();
+ id = *argv;
} else if (matches(*argv, "from") == 0) {
NEXT_ARG();
- get_prefix(&filter.msrc, *argv, AF_INET);
+ get_prefix(&filter.msrc, *argv, family);
} else {
if (strcmp(*argv, "to") == 0) {
NEXT_ARG();
}
if (matches(*argv, "help") == 0)
usage();
- get_prefix(&filter.mdst, *argv, AF_INET);
+ get_prefix(&filter.mdst, *argv, family);
}
- argv++; argc--;
+ argc--; argv++;
}
- read_viftable();
- read_mroute_list(stdout);
- return 0;
+ ll_init_map(&rth);
+
+ if (id) {
+ int idx;
+
+ if ((idx = ll_name_to_index(id)) == 0) {
+ fprintf(stderr, "Cannot find device \"%s\"\n", id);
+ return -1;
+ }
+ filter.iif = idx;
+ }
+
+ if (rtnl_wilddump_request(&rth, filter.af, RTM_GETROUTE) < 0) {
+ perror("Cannot send dump request");
+ return 1;
+ }
+
+ if (rtnl_dump_filter(&rth, print_mroute, stdout) < 0) {
+ fprintf(stderr, "Dump terminated\n");
+ exit(1);
+ }
+
+ exit(0);
}
int do_multiroute(int argc, char **argv)
--
1.8.0.1
^ permalink raw reply related
* [PATCH] return the devices dummyX to the initial network namespace after container closure.
From: V. Lavrov @ 2012-12-13 9:13 UTC (permalink / raw)
To: netdev
If container has a network device dummyX (with lxc.network.type = phys), then it disappears from the system after you close the container.
The patch returns the device dummyX to the initial network namespace after container is closed.
Signed-off-by: Vitaly Lavrov <lve@guap.ru>
---
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index bab0158..efa990c 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -160,6 +160,41 @@ static struct rtnl_link_ops dummy_link_ops __read_mostly = {
module_param(numdummies, int, 0);
MODULE_PARM_DESC(numdummies, "Number of dummy pseudo devices");
+
+static void __net_exit dummy_net_exit(struct net *net) {
+ struct net_device *dev, *aux;
+ int err;
+
+ if(net == &init_net) return;
+
+ rtnl_lock();
+ for_each_netdev_safe(net, dev, aux) {
+ if(dev->rtnl_link_ops == &dummy_link_ops) {
+ err = dev_change_net_namespace(dev, &init_net, dev->name);
+ if(err) {
+ char fb_name[IFNAMSIZ];
+ printk (KERN_INFO "%s: dev_change_net_namespace(init_net,%s) err: %d\n",
+ __func__,dev->name,err);
+ snprintf(fb_name, IFNAMSIZ, "dev%d", dev->ifindex);
+ err = dev_change_net_namespace(dev, &init_net, dev->name);
+ if(err)
+ printk (KERN_INFO "%s: dev_change_net_namespace(%s,init_net,%s) err: %d\n",
+ __func__,dev->name,fb_name,err);
+ else
+ printk (KERN_INFO "%s: %s rename to %s\n",
+ __func__,dev->name,fb_name);
+
+ }
+ }
+ }
+ rtnl_unlock();
+}
+
+static struct pernet_operations __net_initdata dummy_net_ops = {
+ .exit = dummy_net_exit,
+};
+
+
static int __init dummy_init_one(void)
{
struct net_device *dev_dummy;
@@ -184,6 +219,10 @@ static int __init dummy_init_module(void)
{
int i, err = 0;
+ err = register_pernet_device(&dummy_net_ops);
+ if(err)
+ return err;
+
rtnl_lock();
err = __rtnl_link_register(&dummy_link_ops);
@@ -191,8 +230,10 @@ static int __init dummy_init_module(void)
err = dummy_init_one();
cond_resched();
}
- if (err < 0)
+ if (err < 0) {
__rtnl_link_unregister(&dummy_link_ops);
+ unregister_pernet_device(&dummy_net_ops);
+ }
rtnl_unlock();
return err;
@@ -201,6 +242,7 @@ static int __init dummy_init_module(void)
static void __exit dummy_cleanup_module(void)
{
rtnl_link_unregister(&dummy_link_ops);
+ unregister_pernet_device(&dummy_net_ops);
}
module_init(dummy_init_module);
--
^ permalink raw reply related
* Re: [RFC PATCH] xfrm: avoid to send/receive the exceeding hard lifetime data
From: Steffen Klassert @ 2012-12-13 10:14 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1355387152-9963-1-git-send-email-roy.qing.li@gmail.com>
On Thu, Dec 13, 2012 at 04:25:52PM +0800, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> If setkey sets both bh and bs as 1024, and the total send and receive package
> size is 1024, then if next package size is too large, this package should be
> discard.
>
> Example, first package size is 1000, send success, then the second package
> is 500, 1000+500 is larger than 1024, so the second package should be discard.
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
> ---
> net/xfrm/xfrm_input.c | 6 +++---
> net/xfrm/xfrm_output.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> index ab2bb42..d0de8f3 100644
> --- a/net/xfrm/xfrm_input.c
> +++ b/net/xfrm/xfrm_input.c
> @@ -178,6 +178,9 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
> goto drop_unlock;
> }
>
> + x->curlft.bytes += skb->len;
> + x->curlft.packets++;
> +
This is a bit critical on input. We should only increment these values
if the integrity check on this packet was successfull. Otherwise someone
could spam us with invalid packets and trigger a state expiry.
If a synchronous crypto algorithm is used, we send at most one packet too
much. The maximal byte count was not yet reached and RFC 2401 says not
much on how to handle the packet that reaches the maximal byte count,
so this is probaply ok.
But if an asynchronous crypto algorithm is used, we can send a lot
of packets too much. So we should probaply add a second expiry check
after resume from asynchronous crypto. We do this already with the replay
check.
^ permalink raw reply
* Re: [PATCH] xfrm: do not check x->km.state
From: Steffen Klassert @ 2012-12-13 10:19 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1355389560-7705-1-git-send-email-roy.qing.li@gmail.com>
On Thu, Dec 13, 2012 at 05:06:00PM +0800, roy.qing.li@gmail.com wrote:
> From: Li RongQing <roy.qing.li@gmail.com>
>
> do not check x->km.state, it will be checked by succedent
> xfrm_state_check_expire()
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
> ---
> net/ipv6/xfrm6_input.c | 1 -
> net/xfrm/xfrm_input.c | 4 ----
> 2 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
> index f8c3cf8..de4babd 100644
> --- a/net/ipv6/xfrm6_input.c
> +++ b/net/ipv6/xfrm6_input.c
> @@ -108,7 +108,6 @@ int xfrm6_input_addr(struct sk_buff *skb, xfrm_address_t *daddr,
> spin_lock(&x->lock);
>
> if ((!i || (x->props.flags & XFRM_STATE_WILDRECV)) &&
> - likely(x->km.state == XFRM_STATE_VALID) &&
> !xfrm_state_check_expire(x)) {
> spin_unlock(&x->lock);
> if (x->type->input(x, skb) > 0) {
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> index ab2bb42..a8fbb09 100644
> --- a/net/xfrm/xfrm_input.c
> +++ b/net/xfrm/xfrm_input.c
> @@ -163,10 +163,6 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
> skb->sp->xvec[skb->sp->len++] = x;
>
> spin_lock(&x->lock);
> - if (unlikely(x->km.state != XFRM_STATE_VALID)) {
> - XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEINVALID);
> - goto drop_unlock;
> - }
This would remove the only place where the LINUX_MIB_XFRMINSTATEINVALID
statistics counter is incremented. I think it would be better to ensure
a valid state before we call xfrm_state_check_expire(). This would make
the statistics more accurate and we can remove the x->km.state check
from xfrm_state_check_expire().
^ permalink raw reply
* Re: netconsole fun
From: Cong Wang @ 2012-12-13 10:33 UTC (permalink / raw)
To: netdev
In-Reply-To: <1355345957.2687.18.camel@thor>
On Wed, 12 Dec 2012 at 20:59 GMT, Peter Hurley <peter@hurleysoftware.com> wrote:
>
> Just wondering if you think something like the patch below is
> suitable/acceptable for insulating netconsole from inconsistent device
> name scenarios without changing the existing semantics. The basic idea
> is to allow an ethernet MAC address in the <dev> field of the
> netconsole= options, and if a MAC address was specified rather than a
> device name, to do the dev lookup from the MAC address instead.
>
> This doesn't extend to, but also doesn't interfere with, the dynamic
> config of netconsole via configfs.
>
> Would you mind reviewing it?
>
This is a good idea. Just that you need to complete the configfs
interface too.
^ permalink raw reply
* Re: tc ipt action
From: Jamal Hadi Salim @ 2012-12-13 10:58 UTC (permalink / raw)
To: Yury Stankevich; +Cc: netdev@vger.kernel.org, pablo
In-Reply-To: <50C4821D.5090206@gmail.com>
Yury,
This appears to be an ABI breakage on iptables/netfilter side.
I will look at it (and hopefully fix it) over the weekend.
cheers,
jamal
On 12-12-09 07:20 AM, Yury Stankevich wrote:
> Hello,
>
> i not sure this is correct list, please advise if not.
>
> i'm trying to use ipt action, and got a problem:
>
> #tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
> action ipt -j CONNMARK --restore-mark action mirred egress redirect dev ifb0
> -> bad action type ipt
>
> from strace:
> open("/usr/lib/tc//m_gact.so", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> write(2, "bad action type ipt\n", 20bad action type ipt
>
> well. i'm trying to use xt:
> #tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0
> action xt -j CONNMARK --restore-mark action mirred egress redirect dev ifb0
> xt: unrecognized option '--restore-mark'
>
> from strace:
> open("/lib/xtables/libxt_CONNMARK.so", O_RDONLY) = 4
> read(4,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\6\0\0004\0\0\0"...,
> 512) = 512
> fstat64(4, {st_mode=S_IFREG|0644, st_size=9756, ...}) = 0
> mmap2(NULL, 12548, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0)
> = 0xf76f3000
> mmap2(0xf76f5000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1) = 0xf76f5000
> close(4) = 0
> mprotect(0xf76f5000, 4096, PROT_READ) = 0
> socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 4
> fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
> lstat64("/proc/net/ip_tables_names", {st_mode=S_IFREG|0440, st_size=0,
> ...}) = 0
> statfs64("/proc/net/ip_tables_names", 84, {f_type="PROC_SUPER_MAGIC",
> f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0,
> f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
> getsockopt(4, SOL_IP, 0x43 /* IP_??? */,
> "CONNMARK\0\367\f\300\0\0\0po\367l8p\367\364/p\367:}\302\1", [30]) = 0
> close(4) = 0
> write(2, "xt: unrecognized option '--resto"..., 41xt: unrecognized
> option '--restore-mark'
>
> so... i make something wrong or this is a bug ?
>
> ps: 3.6.8 kernel 64 bit kernel with 32 bit userspace, iproute 20121001
> from debian-experimental,
> module act_ipt is loaded.
> pps: please, cc me in reply.
>
>
^ permalink raw reply
* Re: [PATCH 1/1] net: cpts: fix for build break after ARM SoC integration
From: Tomi Valkeinen @ 2012-12-13 11:07 UTC (permalink / raw)
To: Mugunthan V N
Cc: netdev, davem, linux-arm-kernel, linux-omap, b-cousson, paul,
richardcochran
In-Reply-To: <1354012034-31686-1-git-send-email-mugunthanvnm@ti.com>
Hi,
On 2012-11-27 12:27, Mugunthan V N wrote:
> CC drivers/net/ethernet/ti/cpts.o
> drivers/net/ethernet/ti/cpts.c:30:24: fatal error: plat/clock.h: No such file or directory
> compilation terminated.
> make[4]: *** [drivers/net/ethernet/ti/cpts.o] Error 1
> make[3]: *** [drivers/net/ethernet/ti] Error 2
> make[2]: *** [drivers/net/ethernet] Error 2
> make[1]: *** [drivers/net] Error 2
>
> fix for build break as the header file is removed from plat-omap as part of
> the below patch
linux-next still has this build problem, I guess this patch is lingering
somewhere. Somewhat annoying, as the driver is enabled by default. (btw,
why is it "default y"?)
Tomi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox