Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2300100imm; Mon, 28 May 2018 05:40:16 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoxn47bdA3K805yHbYlC08ubSFM9v9afwMaCRhpsCX1ZvNiR1WTmy2vd0OnGR7+9AtFRCh1 X-Received: by 2002:a65:578b:: with SMTP id b11-v6mr10714199pgr.57.1527511216420; Mon, 28 May 2018 05:40:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527511216; cv=none; d=google.com; s=arc-20160816; b=eUjNi5lNAG+A5EOwDuUlZhyEMUj5Nmc6bpt7sR1DtWegr+Tup0KFN6lms8f7A55Nbd Hlhx/lqIygRfuWMsAZugtD0bHS+7uZ7aHOONIBYUUXu7prFKGBm3lHLiL8+nsyTL4VYF 6+MbGoBZiA8HluLvVvZyn1y2Zmb1FSk0PiF9dI9sIU511m1YmZaGNuYJwhAPJIDdaaUS hCLYhBzdNXhIKZxjhPJKKWSBzdn2G+RMeo0j2j095inibbjacUq7oPbgi3+54i0VjeWU 2QLgBIZ2FiHUtG8eCmmGp5z/qOxwlxh8/0JZcXod23lyz3aUrGnD2tKELt8f97d1H23O J3aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=sX3IjYTtS47aPoyIum8v7iCcx6hcspM2LiKt4UAIgsI=; b=PzfosYOAXbMqueEOTjufQEEYupNjlluMEQxvW/02Ad8JK79E/KGDtU7HfQGhxX+7bX /Rf4LSpMKgL1Rd3CrYkXrblWcM5Ar7ZTdEg5QzmOC414nJKm8G904IzZ2L1uTMjOSF3Y xlny6KPFVwWtTId855iZKwDH++CmmJpnOi1OWa+M/s1FylkBxapVMnNMh3s/5Aza1rL9 CyKirWavj00hgPL5Kqasrm4A00144wJ3Pt3yDAMrDpl2lzG3Iv0OrMiovl5gECJKCFJc G/+INm72C+86rfwcWoRiO5BsKdF4pjefwV+BWadRweiL4sBmlyoUqkZ8Vz6lv6h46xWp UQXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=E9jef2q8; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j84-v6si30272619pfk.203.2018.05.28.05.40.01; Mon, 28 May 2018 05:40:16 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=E9jef2q8; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1164648AbeE1MjM (ORCPT + 99 others); Mon, 28 May 2018 08:39:12 -0400 Received: from mail-yb0-f193.google.com ([209.85.213.193]:35049 "EHLO mail-yb0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938032AbeE1MjG (ORCPT ); Mon, 28 May 2018 08:39:06 -0400 Received: by mail-yb0-f193.google.com with SMTP id y3-v6so4045699ybb.2; Mon, 28 May 2018 05:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sX3IjYTtS47aPoyIum8v7iCcx6hcspM2LiKt4UAIgsI=; b=E9jef2q8ffJkM6X2PkELB6NQYcUqgxmXS+mABWHzdNznKfKhGDe35dcdnYWQn2JnXU nLShgDHiUEXreF4tmPZ8Ld+3+zdZE3DbRoxd+kPLtItG1XHJHzyK+kkI7jVU9mzbeJSC M9kexkPNSKIhmOPE/85ijchue5mxR+VvF2jvGYXrvHDAXXD4BJA5Bw9NyNaz9byHTp1e wCSVpGijAvn4bhxqTDIp2YfxrN1JLpHvSN1z1IISQ+/vCz34953LtMF9oTxCIGD0i0LF hluZPnCyfAI07xK2SKbnGItj6kxZoJ2LmmACY7w5KibYTAeC+KjpJLjLtxeN+ne8siRk Bk4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sX3IjYTtS47aPoyIum8v7iCcx6hcspM2LiKt4UAIgsI=; b=hfAZmmxkRfHgfLg8MQgYer5emIw6UulxfEF7JrwG5r2uWo5JAaRyeP/fp3yviHxXNU QX2vkjht9clur0ouehGL7giJPVbNDXB1fB+w4SvbugODO3GNPEFF9eSbXHHZd1KV4z20 KX5ijvymTY702b/mcl6/AGf2EXc47sfe/k9P2xB/HRqlW368sag2goDk/4ECg0pzmsaR BI9WxNsdKFklvmLKbX6iZCU91GRq1yToB8je8qFn9pUDHdGNhcAcaT5pCK5q/M5+RFI/ t+K70il7imPk3WY24YUuiI20Ie+QQJasPuH8pIOx02Xoyu52DBmPTxUOfTSXyY3G72Vw 0RLg== X-Gm-Message-State: ALKqPwdFX9CufGpTiuViH80WfAyh4uSm23Ivitg1cz5FggOidbKmqxjC hCA8mP2AYx8pkAmRuhQaqzkADqfNRz6FLxWn/wQ= X-Received: by 2002:a25:e485:: with SMTP id b127-v6mr7396896ybh.162.1527511145581; Mon, 28 May 2018 05:39:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0d:efc6:0:0:0:0:0 with HTTP; Mon, 28 May 2018 05:39:04 -0700 (PDT) In-Reply-To: <20180528100259.797799079@linuxfoundation.org> References: <20180528100240.256525891@linuxfoundation.org> <20180528100259.797799079@linuxfoundation.org> From: Amir Goldstein Date: Mon, 28 May 2018 15:39:04 +0300 Message-ID: Subject: Re: [PATCH 4.16 231/272] fanotify: Avoid lost events due to ENOMEM for unlimited queues To: Greg Kroah-Hartman Cc: linux-kernel , stable , Jan Kara , Sasha Levin Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 28, 2018 at 1:04 PM, Greg Kroah-Hartman wrote: > 4.16-stable review patch. If anyone has any objections, please let me know. > I do not have objections for applying this patch to stable, but AFAIK it is a correctness patch that doesn't fix any bug and it was mainly added as a prerequisite to memcg accounting of event allocations, which is not yet merged and not destined for stable. Jan? do you agree with my statements above? Thanks, Amir. > ------------------ > > From: Jan Kara > > [ Upstream commit 1f5eaa90010ed7cf0ae90a526c48657d02c6086f ] > > Fanotify queues of unlimited length do not expect events can be lost. > Since these queues are used for system auditing and other security > related tasks, loosing events can even have security implications. > Currently, since the allocation is small (32-bytes), it cannot fail > however when we start accounting events in memcgs, allocation can start > failing. So avoid loosing events due to failure to allocate memory by > making event allocation use __GFP_NOFAIL. > > Reviewed-by: Amir Goldstein > Signed-off-by: Jan Kara > Signed-off-by: Sasha Levin > Signed-off-by: Greg Kroah-Hartman > --- > fs/notify/fanotify/fanotify.c | 19 ++++++++++++++----- > fs/notify/fanotify/fanotify.h | 3 ++- > fs/notify/fanotify/fanotify_user.c | 2 +- > 3 files changed, 17 insertions(+), 7 deletions(-) > > --- a/fs/notify/fanotify/fanotify.c > +++ b/fs/notify/fanotify/fanotify.c > @@ -135,23 +135,32 @@ static bool fanotify_should_send_event(s > return false; > } > > -struct fanotify_event_info *fanotify_alloc_event(struct inode *inode, u32 mask, > +struct fanotify_event_info *fanotify_alloc_event(struct fsnotify_group *group, > + struct inode *inode, u32 mask, > const struct path *path) > { > struct fanotify_event_info *event; > + gfp_t gfp = GFP_KERNEL; > + > + /* > + * For queues with unlimited length lost events are not expected and > + * can possibly have security implications. Avoid losing events when > + * memory is short. > + */ > + if (group->max_events == UINT_MAX) > + gfp |= __GFP_NOFAIL; > > if (fanotify_is_perm_event(mask)) { > struct fanotify_perm_event_info *pevent; > > - pevent = kmem_cache_alloc(fanotify_perm_event_cachep, > - GFP_KERNEL); > + pevent = kmem_cache_alloc(fanotify_perm_event_cachep, gfp); > if (!pevent) > return NULL; > event = &pevent->fae; > pevent->response = 0; > goto init; > } > - event = kmem_cache_alloc(fanotify_event_cachep, GFP_KERNEL); > + event = kmem_cache_alloc(fanotify_event_cachep, gfp); > if (!event) > return NULL; > init: __maybe_unused > @@ -206,7 +215,7 @@ static int fanotify_handle_event(struct > return 0; > } > > - event = fanotify_alloc_event(inode, mask, data); > + event = fanotify_alloc_event(group, inode, mask, data); > ret = -ENOMEM; > if (unlikely(!event)) > goto finish; > --- a/fs/notify/fanotify/fanotify.h > +++ b/fs/notify/fanotify/fanotify.h > @@ -52,5 +52,6 @@ static inline struct fanotify_event_info > return container_of(fse, struct fanotify_event_info, fse); > } > > -struct fanotify_event_info *fanotify_alloc_event(struct inode *inode, u32 mask, > +struct fanotify_event_info *fanotify_alloc_event(struct fsnotify_group *group, > + struct inode *inode, u32 mask, > const struct path *path); > --- a/fs/notify/fanotify/fanotify_user.c > +++ b/fs/notify/fanotify/fanotify_user.c > @@ -757,7 +757,7 @@ SYSCALL_DEFINE2(fanotify_init, unsigned > group->fanotify_data.user = user; > atomic_inc(&user->fanotify_listeners); > > - oevent = fanotify_alloc_event(NULL, FS_Q_OVERFLOW, NULL); > + oevent = fanotify_alloc_event(group, NULL, FS_Q_OVERFLOW, NULL); > if (unlikely(!oevent)) { > fd = -ENOMEM; > goto out_destroy_group; > >