Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754242AbdCBHiK (ORCPT ); Thu, 2 Mar 2017 02:38:10 -0500 Received: from mail-lf0-f66.google.com ([209.85.215.66]:36141 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753313AbdCBHiJ (ORCPT ); Thu, 2 Mar 2017 02:38:09 -0500 From: Valentine Sinitsyn To: linux-kernel@vger.kernel.org Cc: Valentine Sinitsyn Subject: [RFC] [PATCH] net: account for possible negative frag_mem_limit Date: Thu, 2 Mar 2017 12:37:52 +0500 Message-Id: <1488440272-10915-1-git-send-email-valentine.sinitsyn@gmail.com> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1219 Lines: 36 I'm also not sure if we'd better disable bottom halves before calculating the counter sum, as sum_frag_mem_limit() does. --- 8< --- On SMP systems, percpu_counter_sum() is permitted to return negative values. However, inet_frag_exit_net() function is following the assumption that its return value is either positive or zero. If a negative value is returned, the code loops forever, possibly keeping net_mutex locked. This could break many things, including unshare(CLONE_NEWNET) system call which would hang forever. Fix this by explicitly asking for a positive return value from the percpu counter. Signed-off-by: Valentine Sinitsyn --- net/ipv4/inet_fragment.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c index b5e9317..0a63c9e 100644 --- a/net/ipv4/inet_fragment.c +++ b/net/ipv4/inet_fragment.c @@ -234,7 +234,7 @@ void inet_frags_exit_net(struct netns_frags *nf, struct inet_frags *f) cond_resched(); if (read_seqretry(&f->rnd_seqlock, seq) || - percpu_counter_sum(&nf->mem)) + percpu_counter_sum_positive(&nf->mem)) goto evict_again; percpu_counter_destroy(&nf->mem); -- 2.7.4