Just updated a node to current master (+https://github.com/bitcoin/bitcoin/pull/7685), the node ran successfully for a couple of weeks, shortly after updating to current master, I ran in a deadlock assertion:
I think the possible deadlock is not related to the PR which I'm running on top.

```
2016-08-26 07:50:29 POTENTIAL DEADLOCK DETECTED
2016-08-26 07:50:29 Previous lock order was:
2016-08-26 07:50:29  pnode->cs_vRecvMsg  net.cpp:1885 (TRY)
2016-08-26 07:50:29  cs_main  main.cpp:4726
2016-08-26 07:50:29  (1) pfrom->cs_filter  main.cpp:4784
2016-08-26 07:50:29  (2) cs_vSend  net.cpp:2683
2016-08-26 07:50:29 Current lock order is:
2016-08-26 07:50:29  (2) pnode->cs_vSend  net.cpp:1904 (TRY)
2016-08-26 07:50:29  cs_main  main.cpp:6343 (TRY)
2016-08-26 07:50:29  pto->cs_inventory  main.cpp:6563
2016-08-26 07:50:29  (1) pto->cs_filter  main.cpp:6586
```

int nLastBlockFile = 0;
    /** Global flag to indicate we should check to see if there are
     *  block/undo files that should be deleted.  Set on startup
     *  or if we allocate more file space when we're in prune mode
     */
    bool fCheckForPruning = false;
    /**
     * Every received block is assigned a unique and increasing identifier, so we
     * know which one to give priority in case of a fork.
     */
    CCriticalSection cs_nBlockSequenceId;
    
    uint32_t nBlockSequenceId = 1;
    /**
     * Sources of received blocks, saved to be able to send them reject
     * messages or ban them when processing happens afterwards. Protected by
     * cs_main.
     */
    map<uint256, NodeId> mapBlockSource;
    /**
     * Filter for transactions that were recently rejected by
     * AcceptToMemoryPool. These are not rerequested until the chain tip
     * changes, at which point the entire filter is reset. Protected by
     * cs_main.
     *
     * Without this filter we'd be re-requesting txs from each of our peers,
     * increasing bandwidth consumption considerably. For instance, with 100
     * peers, half of which relay a tx we don't accept, that might be a 50x
     * bandwidth increase. A flooding attacker attempting to roll-over the
     * filter using minimum-sized, 60byte, transactions might manage to send