Received: by 10.192.165.156 with SMTP id m28csp1619628imm; Wed, 18 Apr 2018 12:44:12 -0700 (PDT) X-Google-Smtp-Source: AIpwx49hYlIc6OX1Zcs5RzdI5Bw9JNoTX/MVnM070/hjiSh1JnNL2WMdkbJh0G5RQltA8O/i1goD X-Received: by 10.98.102.79 with SMTP id a76mr3111522pfc.162.1524080652230; Wed, 18 Apr 2018 12:44:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524080652; cv=none; d=google.com; s=arc-20160816; b=iARhHfqku+T8SbcKQ/BsUBGLyUv45gaGUsHMgqCqbCqyVelAWVltn2W0nRqybRjcet 3h4pjKx+xHZdUTtu4VRFwFg/R3ZXpz73fabbq9WRBrnkESVICj6vELVlqI8Nvo0/5xtw 64inQ0L2s80lioc/iBNt4GzvcC3GCqOvlhvufMCYUjyQSN21e03cFKLHVyWi13Y/BYwF iwTPuqmOuXqO9AFADg68iCIp9OuKu59Z2nwPB/d2BtEyHDUJoBj6vb90kQINZPmO/pCv QD7t+efwodihlxDUGRjR/oLsqAyBmnqttTGxqOHwdqhXFSguKMeouIqvGYNMkhznc2Am 1kwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=5nsYo5OGCjWrKFtPPWYRRNINV1USs8XAJA8yYDWwmF0=; b=MYG14fL4MDviNBI+G+gxt6gyY2GRocgyfPLBK9AavtMwIK0dMV6eyTPkDkwxQwwLxM O73DPpo/UOBJ8m2md7Tm4IRi1z7JVasqqG5xJCIrYg9I1lIUaXp/FY8SVuo9tNwxNeg/ SZZRgcUjkkgyxfqu7wRZURE9Vsa5saVT7MM5cTYcXhtdARqW7vjCZ0QEpcB+12/dm7X7 HexBtqGvWyQV9s9E1/bXBS1wdmPschw75YUb/qr4jR3XZ9px0eaIoPRRapXomNRgvpnB BdvpvPnchUsbS+lfDAdzv0s2n4tn3JJtWh6gI5vg2noTleF74MuTvX8bt3IKek73QGtQ O+IA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e63si1624502pfg.344.2018.04.18.12.43.58; Wed, 18 Apr 2018 12:44:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752308AbeDRTmx (ORCPT + 99 others); Wed, 18 Apr 2018 15:42:53 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:50998 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750872AbeDRTmw (ORCPT ); Wed, 18 Apr 2018 15:42:52 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.71]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 077B818581; Wed, 18 Apr 2018 19:42:52 +0000 (UTC) Date: Wed, 18 Apr 2018 12:42:51 -0700 From: Andrew Morton To: Chengguang Xu Cc: linux-fsdevel@vger.kernel.org, dhowells@redhat.com, kstewart@linuxfoundation.org, gregkh@linuxfoundation.org, tglx@linutronix.de, pombredanne@nexb.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] hfs: fix potential refcnt problem of nls module Message-Id: <20180418124251.d66a36cb23673f0d8b152910@linux-foundation.org> In-Reply-To: <1523948733-8537-1-git-send-email-cgxu519@gmx.com> References: <1523948733-8537-1-git-send-email-cgxu519@gmx.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 17 Apr 2018 15:05:32 +0800 Chengguang Xu wrote: > When specifying iocharset/codepage multiple times in a mount, > current option parsing will cause inaccurate refcount of nls > module. Hence, call unload_nls for previous one in this case. > > ... > > --- a/fs/hfs/super.c > +++ b/fs/hfs/super.c > @@ -329,8 +329,10 @@ static int parse_options(char *options, struct hfs_sb_info *hsb) > return 0; > } > p = match_strdup(&args[0]); > - if (p) > + if (p) { > + unload_nls(hsb->nls_disk); > hsb->nls_disk = load_nls(p); > + } > if (!hsb->nls_disk) { > pr_err("unable to load codepage \"%s\"\n", p); > kfree(p); > @@ -344,8 +346,10 @@ static int parse_options(char *options, struct hfs_sb_info *hsb) > return 0; > } > p = match_strdup(&args[0]); > - if (p) > + if (p) { > + unload_nls(hsb->nls_io); > hsb->nls_io = load_nls(p); > + } > if (!hsb->nls_io) { > pr_err("unable to load iocharset \"%s\"\n", p); > kfree(p); Confused. break; : case opt_codepage: : if (hsb->nls_disk) { : pr_err("unable to change codepage\n"); : return 0; : } Here, hsb->nls_disk is known to be zero. : p = match_strdup(&args[0]); : if (p) { : unload_nls(hsb->nls_disk); So this will always do unload_nls(0). : hsb->nls_disk = load_nls(p); : } And the same applies to your opt_iocharset change.