Received: by 10.213.65.68 with SMTP id h4csp1898336imn; Thu, 29 Mar 2018 13:10:54 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+toSDuUqfBaCR3NZDp3ciMIgnxzrkWW8G+12pVhzpf+LegJefeGO+u4Oxdd2nOvji8TWWf X-Received: by 2002:a17:902:2006:: with SMTP id n6-v6mr9909621pla.150.1522354254477; Thu, 29 Mar 2018 13:10:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522354254; cv=none; d=google.com; s=arc-20160816; b=jAt1dKJ4A4dObD1tO/vaEL7tjZRzd3JC+YV+2iX4AcmGojWrf3BvEdtkWd9N+giMW+ HnimzZnev/acM2+cIuSBoR8fxdnaNM9Gs+f/zyAQuBwmFntGA/aqtGrIoq1eqtMNWlcX mIykHzyjlM/oBD1jeWUuqzk9tvLFwlO3PVLL61PHqTZkGs9u5YiUexb1lpJHCQrAYiF1 vMhhzH9mLWzoksp7wfj4q8rFgxi4m9KBMna/GhV6VldGwAtOYnXRX/dIQmsQOI5zaHVb 1KtbaHbxx1V85KOy7o30k15ZGKdHXdCAEmdv9JI9WM72KqE/eDAY1XQQW1HZLhZVOPdL Hcpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:content-transfer-encoding :mime-version:user-agent:message-id:in-reply-to:date:references:cc :to:from:arc-authentication-results; bh=GsvPcWtLzQhFxconfqig3YkglQwnjxYB2B/zldQe0BM=; b=0Tnao+4nnKT9efFL4cW2L6YcCnGEFSCY+64qFpKH2XbLRFx4C5OxzkxrLQirvUBwYc jT6InRXTdDuyJVp4Fm6tn37R5MqelgTlhwM7kxNqPpfB1ntHxhwWb4Bq3eR5z1OF0jj5 EIeT5Fe5czTe4/vQgw6wyhyetmcwWvgk3mErm0vgzyD+gR9xbj2z0A9Q1KUszjx49dAN RoZq2ak93Zjr3UBgD0wPLVGvYZaOyF2yvyoxbiai9XbZjmitP7nBAX7mlyzowKTDkUEy rW9Hm77Dwne3xyZbT2vxJnDZ0NX6VfJHqcA5yZjRWHxugafjzQNX0IbGjEEBPCh2CCeJ 8L1A== 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 v2si4560557pgf.530.2018.03.29.13.10.34; Thu, 29 Mar 2018 13:10:54 -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 S1751227AbeC2UJO convert rfc822-to-8bit (ORCPT + 99 others); Thu, 29 Mar 2018 16:09:14 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:52496 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751082AbeC2UJM (ORCPT ); Thu, 29 Mar 2018 16:09:12 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1f1dr8-00007i-80; Thu, 29 Mar 2018 14:09:06 -0600 Received: from 67-3-145-25.omah.qwest.net ([67.3.145.25] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1f1dr6-0001mC-GI; Thu, 29 Mar 2018 14:09:06 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Manfred Spraul Cc: Davidlohr Bueso , Waiman Long , Michael Kerrisk , "Luis R. Rodriguez" , Kees Cook , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Al Viro , Matthew Wilcox , Stanislav Kinsbursky , Linux Containers , linux-api@vger.kernel.org References: <1520885744-1546-1-git-send-email-longman@redhat.com> <1520885744-1546-5-git-send-email-longman@redhat.com> <87woyfyh57.fsf@xmission.com> <5d4a858a-3136-5ef4-76fe-a61e7f2aed56@redhat.com> <87o9jru3bf.fsf@xmission.com> <935a7c50-50cc-2dc0-33bb-92c000d039bc@redhat.com> <87woyego2u.fsf_-_@xmission.com> <047c6ed6-6581-b543-ba3d-cadc543d3d25@redhat.com> <87h8ph6u67.fsf@xmission.com> <7d3a1f93-f8e5-5325-f9a7-0079f7777b6f@redhat.com> <20180329021409.gcjjrmviw2lckbfk@linux-n805> <3e201de2-bed2-6f7d-0783-700d095142e0@colorfullife.com> Date: Thu, 29 Mar 2018 15:08:01 -0500 In-Reply-To: <3e201de2-bed2-6f7d-0783-700d095142e0@colorfullife.com> (Manfred Spraul's message of "Thu, 29 Mar 2018 10:47:45 +0200") Message-ID: <87y3ia3ase.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1f1dr6-0001mC-GI;;;mid=<87y3ia3ase.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.145.25;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+bzGMlP7Kq5tqGNqizT3u+KsbSXhZ2tZk= X-SA-Exim-Connect-IP: 67.3.145.25 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sa03.xmission.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,TR_Symld_Words,TVD_RCVD_IP,T_TM2_M_HEADER_IN_MSG autolearn=disabled version=3.4.0 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Manfred Spraul X-Spam-Relay-Country: X-Spam-Timing: total 1390 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.1 (0.2%), b_tie_ro: 2.1 (0.2%), parse: 1.60 (0.1%), extract_message_metadata: 28 (2.0%), get_uri_detail_list: 4.3 (0.3%), tests_pri_-1000: 11 (0.8%), tests_pri_-950: 2.3 (0.2%), tests_pri_-900: 1.90 (0.1%), tests_pri_-400: 40 (2.9%), check_bayes: 38 (2.7%), b_tokenize: 17 (1.2%), b_tok_get_all: 9 (0.6%), b_comp_prob: 4.7 (0.3%), b_tok_touch_all: 3.5 (0.3%), b_finish: 0.89 (0.1%), tests_pri_0: 1273 (91.6%), check_dkim_signature: 1.09 (0.1%), check_dkim_adsp: 5.0 (0.4%), tests_pri_500: 22 (1.6%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC][PATCH] ipc: Remove IPCMNI X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Manfred Spraul writes: >>>>> On 03/14/2018 08:49 PM, Eric W. Biederman wrote: >>>>>> To make it possible to keep checkpoint/restore working I have renamed >>>>>> the sysctls from xxx_next_id to xxx_nextid.  That is enough change that >>>>>> a smart CRIU implementation can see that what is exported has changed, >>>>>> and act accordingly.  New kernels will be able to restore the old id's. >>>>>> >>>>>> This code still needs some real world testing to verify my assumptions. >>>>>> And some work with the CRIU implementations to actually add the code >>>>>> that deals with the new for of id assignment. >>>>>> > It means that all existing checkpoint/restore application will not work with a > new kernel. > Everyone must first update the checkpoint/restore application, then update the > kernel. > > Is this acceptable? There is no nead. I just reread through how next_id is implementated in ipc/util.c and I had been reading it wrong. There is no need to change the sysctl. What criu needs is an interface that specifies the next_id to allocate both the high and the low bits and that is what this the sysctl provides. The implemenation could use a little cleanup so it is easier to understand something like this perhaps: diff --git a/ipc/util.c b/ipc/util.c index 3783b7991cc7..2d4ec6e5b70b 100644 --- a/ipc/util.c +++ b/ipc/util.c @@ -192,46 +192,32 @@ static struct kern_ipc_perm *ipc_findkey(struct ipc_ids *ids, key_t key) return NULL; } -#ifdef CONFIG_CHECKPOINT_RESTORE -/* - * Specify desired id for next allocated IPC object. - */ -#define ipc_idr_alloc(ids, new) \ - idr_alloc(&(ids)->ipcs_idr, (new), \ - (ids)->next_id < 0 ? 0 : ipcid_to_idx((ids)->next_id),\ - 0, GFP_NOWAIT) - -static inline int ipc_buildid(int id, struct ipc_ids *ids, - struct kern_ipc_perm *new) -{ - if (ids->next_id < 0) { /* default, behave as !CHECKPOINT_RESTORE */ - new->seq = ids->seq++; - if (ids->seq > IPCID_SEQ_MAX) - ids->seq = 0; - } else { - new->seq = ipcid_to_seqx(ids->next_id); - ids->next_id = -1; - } - return SEQ_MULTIPLIER * new->seq + id; -} - -#else -#define ipc_idr_alloc(ids, new) \ - idr_alloc(&(ids)->ipcs_idr, (new), 0, 0, GFP_NOWAIT) - -static inline int ipc_buildid(int id, struct ipc_ids *ids, - struct kern_ipc_perm *new) +static inline int ipc_idr_alloc(struct ipc_ids *ids, struct kern_ipc_perm *new) { + int id; +#ifdef CONFIG_CHECKPOINT_RESTORE + if (unlikely(new->id >= 0)) { + int idx = ipcid_to_idx(new->id); + id = idr_alloc(&ids->ipcs_idr, new, idx, 0, GFP_NOWAIT); + if (id < 0) + return id; + if (id != idx) { + idr_remove(&ids->ipcs_idr, id); + return -EBUSY; + } + new->seq = ipcid_to_seqx(new->id); + return id; + } +#endif + id = idr_alloc(&ids->ipcs_idr, new, 0, 0, GFP_NOWAIT); new->seq = ids->seq++; if (ids->seq > IPCID_SEQ_MAX) ids->seq = 0; - - return SEQ_MULTIPLIER * new->seq + id; + new->id = SEQ_MULTIPLIER * new->seq + id; + return id; } -#endif /* CONFIG_CHECKPOINT_RESTORE */ - /** * ipc_addid - add an ipc identifier * @ids: ipc identifier set @@ -269,6 +255,10 @@ int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int limit) new->cuid = new->uid = euid; new->gid = new->cgid = egid; + new->id = ids->next_id; + if (new->id >= 0) + ids->next_id = -1; + id = ipc_idr_alloc(ids, new); idr_preload_end(); @@ -290,8 +280,6 @@ int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int limit) if (id > ids->max_id) ids->max_id = id; - new->id = ipc_buildid(id, ids, new); - return id; } Eric