From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80FB2E7717D for ; Mon, 9 Dec 2024 10:56:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD5676B0413; Mon, 9 Dec 2024 05:56:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D5E2D6B0414; Mon, 9 Dec 2024 05:56:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB1436B0415; Mon, 9 Dec 2024 05:56:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9624A6B0413 for ; Mon, 9 Dec 2024 05:56:21 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 19D011602FD for ; Mon, 9 Dec 2024 10:56:21 +0000 (UTC) X-FDA: 82875116310.28.615BE62 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf26.hostedemail.com (Postfix) with ESMTP id 15F11140002 for ; Mon, 9 Dec 2024 10:56:02 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="BaJ/pkLD"; spf=pass (imf26.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733741769; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=r0LbryMuat7RH0ATlewYVWKmDIYyFyuiu+TeKBqC3xo=; b=U9wGswPJgZ0n9G2m3Qw9tVMBVTyW5LyvicM0M3VB8aweyqUAJKRRHZdbY6IOPy7RhlKWzc K/n74lAUEYUTLbHhNJDXQ0TcY5mycahOS9ZvZvVbI0U3vkDU2uNeZeFC6kYmnl2UHXThJQ 89w4ne996bMU4HUc6J7BRVmK1Z8mSHw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733741769; a=rsa-sha256; cv=none; b=NtroYlJNbZEIjeaTGpLkOcUPDVz4OUY1CbWTrNQTG5NwS4wUnHzd82tfa7ko8BIbvhipE6 5/UyVQxAyeGh5bouBp61BN8KF/06e7sO/WbiQowoUXWdKqoI3nHM1rRMtEWA5rySGEgSzh mtjt5Am+w0gXN9hBRAl0QY0yyPGvK7w= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="BaJ/pkLD"; spf=pass (imf26.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733741778; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=r0LbryMuat7RH0ATlewYVWKmDIYyFyuiu+TeKBqC3xo=; b=BaJ/pkLDpGKEfIKFsH/Ibojqtr+vnmBNk7kauFuUPQS9fe0z5v0IEnt/XBlegACvOZ/8eo 0OdzoduuEv5oxRiJjg2aVl/OV3fC5uA6lrG+hx9DbmVSyfO366BcEKfIkkUj0YepYCN8ss qcaIBFCWCkkJicsyXO6lx0y/ajoHWT8= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-669-vcBJuTTTOIeLFMaDJtZqBA-1; Mon, 09 Dec 2024 05:56:16 -0500 X-MC-Unique: vcBJuTTTOIeLFMaDJtZqBA-1 X-Mimecast-MFC-AGG-ID: vcBJuTTTOIeLFMaDJtZqBA Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-385d52591d6so2264388f8f.1 for ; Mon, 09 Dec 2024 02:56:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733741775; x=1734346575; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=r0LbryMuat7RH0ATlewYVWKmDIYyFyuiu+TeKBqC3xo=; b=wDKAQcnSQvEKW+g/K8iltkDRVxfTTviomgixQy8YJCS7S049WLEaa/WrAYAP0weuLC 8a9jwRp8C3Kiy62HmIg7bLy9LW8yGmlKee9UpeFJl5RJ/qAbIasVzBF2qTnJbgdw+fs9 X1p63juDmAZ3KSYggo4aePtkuPZv280KX4qRVErYZIdXzQdpqUWh8pLDF6c+lnqe2mFq vMX9XMqIVY2iXE79naJhU92GhFSkWV0Gx1FwlXGExQAubcryYW8fiFwOxxy8QPar6go2 Ms0+J8xQLonH3ZzkqRwtehP2K/E+GUsLKsnhKssebYkTUR/+Sl3lsKXip8A7nIy6Mfmm vQhg== X-Forwarded-Encrypted: i=1; AJvYcCVWgxORIanxBVE6BH3deqmajDCYemxq+2bNpfVqmWvxiVNXPeAq39HF9/qcSqGUOJD6Wd1VqjOnlw==@kvack.org X-Gm-Message-State: AOJu0YyEOYogk20cWAUX9OSkk2zf/G12V/tDUybyJQnSHiNEdnxIipSh LMgUSDnJEx1Da3+Az20U+u31k6V6nTWXV7SpOSM1ogWodtAFK7oyiFIvfSL7360CfqgtRUaqnmi yCVjlkhrScJ2TvndcXMJcaSpgMSxzvAQESRmTPW4Q4/YPNMqt X-Gm-Gg: ASbGncu6adCzQi141BL6jQL9ITQUdrcPWIirj0Hm1EpNJZTELwXDgXaDftFayU/25pF lmq1a+5qXxSmpYSnA6gG+B9l+NI9Ew8utowwbrzVDVA0CWGRwv9Yk3NWpUv4ImfF1j8Vb7r80/J VFC/mctcPd6fNPo0dYkMJjg+5DHbAYa4XFthPQfrdF3sfrX646TCpKFyYRQZXmUI9HkbULdVGNO Vh+7E2FEmPuGl+R8I/1YbeLE8/2ahXj5K09GoK9ywtZ7+g+K9BZOiDb39JqRwwHK/U4IeuxOfL1 tWHtJg/j X-Received: by 2002:a5d:64e8:0:b0:385:ef14:3b55 with SMTP id ffacd0b85a97d-3862a914866mr7419444f8f.19.1733741775656; Mon, 09 Dec 2024 02:56:15 -0800 (PST) X-Google-Smtp-Source: AGHT+IEwcP+cRMRrf3tdHGbxQ+3psA3g0VschafaLoZwoDwMwNQZXeIZnYXR+fpZ3kjCQCiAi/kuXQ== X-Received: by 2002:a5d:64e8:0:b0:385:ef14:3b55 with SMTP id ffacd0b85a97d-3862a914866mr7419428f8f.19.1733741775304; Mon, 09 Dec 2024 02:56:15 -0800 (PST) Received: from ?IPV6:2a09:80c0:192:0:5dac:bf3d:c41:c3e7? ([2a09:80c0:192:0:5dac:bf3d:c41:c3e7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3861f4a8758sm12669019f8f.27.2024.12.09.02.56.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Dec 2024 02:56:14 -0800 (PST) Message-ID: <606fbf9a-c9ba-4f08-a708-db38fe6065ce@redhat.com> Date: Mon, 9 Dec 2024 11:56:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: remove an avoidable load of page refcount in page_ref_add_unless To: Mateusz Guzik Cc: yuzhao@google.com, akpm@linux-foundation.org, willy@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20241207082931.1707465-1-mjguzik@gmail.com> <94d0dcbe-2001-4a9c-a767-b337b688b616@redhat.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Q0qRvqQEhlgUtJvkyZEial1Pc6WvFecDeNCxKMLizPo_1733741776 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 15F11140002 X-Stat-Signature: p6jwms4thkibb1ep7bm99bqu4opegfwa X-Rspam-User: X-HE-Tag: 1733741762-800069 X-HE-Meta: U2FsdGVkX19DoS0KxKQZuVxVteIcnGZh/RTAbKjt0Ow6Z6PjmH1htTshL7zGHtxus6vczzRn7PwTt4CmyTz7iOggktBnmEiRDJCNnU4bz9Cw9PTLQg/2cuDPzu/wPHwJAeVJVVOJUUgoK6pRFtx5lQRrAX42j8VqvhRxdCf9nBFWN7dDxsqrQjoVNFvHK/NoKhi+impbeMxk2hXzliPuRNV0NzY1NeCTni5dqDspRgeCTboEfLlnXXXdBnxzBB4marpHyZjl7K5E6YwHyoZfrCw16KlIt0cERIh26sYhmu22Vje+vU3uuNWsQoh38dc8eIjgIiohK40xMJNPkSSNb7w82c3rp8oxUXYRX4iJmmGhLyW/hRo7fsQtx3onHj4b7Gdhiv5VEGRLoMh/i7Hyra/1DOBhEPuqPUSxtoSb6XRrgGwt0St43jLcyQ0SN1kpY+1mvXNko4dFTnodgOcbOiwi6pQQE//jUsKFAIIoE6pyg59RhV21PIo9SlGrK/OB7hdssAg7qagGCZOZ00FaECZ5DuecDkyn5K2ZK5JNFKuS4T7bJ5VyAgDf8nhUUpJQ2iLhrVsAWNdW9Cq4kSCJRu/JohzB8JRZ9f6XJXzLpb+vszNbuPMTLvVEWxMLvojYsz+8Qso746x5imLzG0QKll7HfxZG/gga4vV3Zv9MhpOTvTcuoxn5zGPZa5dYD1cUnSeRzpzZdR3h4B+BMMxgZB6+MfbR8R7LnT8YxX6w072fT6+//GcrEVKZi/MzPz5BJHC8UkwWiWrxl8XjGktbycJpbD3+UGF2a+UpOi+VQ+2oQy2uhvNn5hMszE4TH22xTBx2UFhllsAU9ojfno2rzqzYWVLNyNzJKDdxcH1G9YLYPYFGifAfejWKwTKJcWaBqSZWd/KCOtJ1wPYAuuhB1zN1vEJabZhok6x0omJpkCAPVXxhmfV/uEpO1w+mbkjx7aD5TuVP5hPR6OPdXb+ FAw50z2R /nd2p5mgvAl7L3Zzjo0hrjUDZd7rjxQh4Ysri+p3Ad6vTjtkVnGzPfOsAlZWvLH6VsvJB9FcfxZ0W3TGdIREBlv5o5Xvx5R1E+H3i3fI5upeJddw2myuuEDuMiHB1k2ytQNk1DnldxHpWULueqibVUlEgMCn+VhIGs2M50Q6uVB726Elwm/kbqqya5S3/tcCX49xH+Pb15yVjpztIlVcr7Ge/Ie5KM7kSl3l47TKxsEeqO86uscJKxJ0mf9V2iHkFzkCm7jZf5KBw12DSVR83Zkr5rOLIKu0itSTqJyxC4gO9cCdr2AdjlT700ft7hIeYCrj1fMjggNVB8b1paQD2vtGbXvxxj/CS/W5NTym5TCZerX4iKAyeLccsSXx39LHbhX4ZwwXKyV8xRtPVgZIhDEkWV5tbmImBdNGKnPWvuG+vJluVydbo4OhPXOjHsrJcmZssOY7YayeOjMhFN6fZGUWl5xzZ/uWyVMr1lxt5aYqvI72BPwYQFvzm3YF2L4gHLWqIoW3qlFZ84fyJ8N5CVhvUgz0KX5w1SXgduPMY0ouXRMnVEXSGfOd2Rx1v1NFv7qzfgeuIz4Jv0a7EjeuzFdaobPLQmbVKc3jgMsaDx5LdnC2FNMBx1OHcdopxphpO8sbBg26GHU3z+ExL1V16DlRtgQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.004595, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 09.12.24 11:25, Mateusz Guzik wrote: > On Mon, Dec 9, 2024 at 10:28 AM David Hildenbrand wrote: >> >> On 07.12.24 09:29, Mateusz Guzik wrote: >>> Explicitly pre-checking the count adds nothing as atomic_add_unless >>> starts with doing the same thing. iow no functional changes. >> >> I recall that we added that check because with the hugetlb vmemmap >> optimization, some of the tail pages we don't ever expect to be modified >> (because they are fake-duplicated) might be mapped R/O. >> >> If the arch implementation of atomic_add_unless() would trigger an >> unconditional write fault, we'd be in trouble. That would likely only be >> the case if the arch provides a dedicate instruction. >> >> atomic_add_unless()->raw_atomic_add_unless() >> >> Nobody currently defines arch_atomic_add_unless(). >> >> raw_atomic_fetch_add_unless()->arch_atomic_fetch_add_unless() is defined >> on some architectures. >> >> I scanned some of the inline-asm, and I think most of them perform a >> check first. >> > > Huh. > > Some arch triggering a write fault despite not changing the value is > not something I thought about. Sounds pretty broken to me if any arch > was to do it, but then stranger things did happen. Yeah, it really depends on what the architecture defines. For example, on s390x for "COMPARE AND SWAP" the spec states something like "When the result of the comparison is unequal, the second operand is loaded at the first-operand loca- tion, and the second-operand location remains unchanged. However, on some models, the contents may be fetched and subsequently stored back unchanged at the second-operand location. This update appears to be a block-concurrent interlocked- update reference as observed by other CPUs." So there might be an unconditional store on an instruction where one would not expect it. Something similar-but-different recently popped up on aarch64, which does what one would expect: "The atomic RMW instructions, for example, ldadd, actually does load + add + store in one instruction, it will trigger two page faults per the ARM64 architecture spec, the first fault is a read fault, the second fault is a write fault. Some applications use atomic RMW instructions to populate memory, for example, openjdk uses atomic-add-0 to do pretouch (populate heap memory at launch time) between v18 and v22 in order to permit use of memory concurrently with pretouch." [1] And Christoph commented: "x86 does not do a read fault on atomics so we have an issue htere." [2] I did not check if that is actually true on x86. > > However, if this is seen as a real concern, then I think the best way > forward is to drop the patch (and maybe instead add a comment what's > up with the extra load). I assume we're currently fine because no architecture actually defines such an instruction that would be a problem for add_unless. [1] https://lore.kernel.org/linux-arm-kernel/Zmw1jltdkMrTrT_l@arm.com/T/ [2] https://lore.kernel.org/linux-arm-kernel/c1ba9ba3-b0d6-4c6c-d628-614751d737c2@gentwo.org/ -- Cheers, David / dhildenb