From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752392AbdBIKDh (ORCPT <rfc822;w@1wt.eu>);
        Thu, 9 Feb 2017 05:03:37 -0500
Received: from mx5-phx2.redhat.com ([209.132.183.37]:38471 "EHLO
        mx5-phx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752043AbdBIKDf (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 9 Feb 2017 05:03:35 -0500
Date: Thu, 9 Feb 2017 05:02:31 -0500 (EST)
From: Jason Wang <jasowang@redhat.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: David Miller <davem@davemloft.net>,
        "Michael S. Tsirkin" <mst@redhat.com>,
        Eric Dumazet <edumazet@google.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Cong Wang <xiyou.wangcong@gmail.com>, netdev <netdev@vger.kernel.org>,
        syzkaller <syzkaller@googlegroups.com>
Message-ID: <50038580.20299907.1486634551103.JavaMail.zimbra@redhat.com>
In-Reply-To: <CACT4Y+bs15VR7xjeYhece+0_X5Ss+5FM0w6jpJH0Dbbdu-+qCQ@mail.gmail.com>
References: <CACT4Y+bs15VR7xjeYhece+0_X5Ss+5FM0w6jpJH0Dbbdu-+qCQ@mail.gmail.com>
Subject: Re: net: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected in
 skb_array_produce
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.68.5.20]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF51 (Linux)/8.0.6_GA_5922)
Thread-Topic: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected in skb_array_produce
Thread-Index: pVcukDoS1XPRPkVEYHe8OiglIXfFeA==
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org



----- Original Message -----
> Hello,
> 
> I've got the following report while running syzkaller fuzzer on mmotm
> (git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git)
> remotes/mmotm/auto-latest ee4ba7533626ba7bf2f8b992266467ac9fdc045e:
> 

[...]

> 
> other info that might help us debug this:
> 
>  Possible interrupt unsafe locking scenario:
> 
>        CPU0                    CPU1
>        ----                    ----
>   lock(&(&r->consumer_lock)->rlock);
>                                local_irq_disable();
>                                lock(&(&r->producer_lock)->rlock);
>                                lock(&(&r->consumer_lock)->rlock);
>   <Interrupt>
>     lock(&(&r->producer_lock)->rlock);
> 

Thanks a lot for the testing.

Looks like we could address this by using skb_array_consume_bh() instead.

Could you pls verify if the following patch works?

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8a7d6b9..a97c00d 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -520,7 +520,7 @@ static void tun_queue_purge(struct tun_file *tfile)
 {
        struct sk_buff *skb;
 
-       while ((skb = skb_array_consume(&tfile->tx_array)) != NULL)
+       while ((skb = skb_array_consume_bh(&tfile->tx_array)) != NULL)
                kfree_skb(skb);
 
        skb_queue_purge(&tfile->sk.sk_write_queue);
@@ -1458,7 +1458,7 @@ static struct sk_buff *tun_ring_recv(struct tun_file *tfile, int noblock,
        struct sk_buff *skb = NULL;
        int error = 0;
 
-       skb = skb_array_consume(&tfile->tx_array);
+       skb = skb_array_consume_bh(&tfile->tx_array);
        if (skb)
                goto out;
        if (noblock) {
@@ -1470,7 +1470,7 @@ static struct sk_buff *tun_ring_recv(struct tun_file *tfile, int noblock,
        current->state = TASK_INTERRUPTIBLE;
 
        while (1) {
-               skb = skb_array_consume(&tfile->tx_array);
+               skb = skb_array_consume_bh(&tfile->tx_array);
                if (skb)
                        break;
                if (signal_pending(current)) {