Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1008539imm; Tue, 5 Jun 2018 07:49:34 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL9ukv8RW17RzGpp/ZHfVh2FGzuPieOLT90+jbEvRlJ2QGY13kizM55DzG91SuPFzBIbPyK X-Received: by 2002:a62:c16:: with SMTP id u22-v6mr9399124pfi.177.1528210174193; Tue, 05 Jun 2018 07:49:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528210174; cv=none; d=google.com; s=arc-20160816; b=pWrjABE7wKsC0VoLksD3ER8d3w65oXxYjOIoP4bnw5s3U/8siv5wNzpJOC9Yx9f82q Nq8UOvK47V+LOa8QF87lwbdi/pu3+XtqW+Fpph37HM9RPC9KZtAJ3RrPOsYKmtATfjsA xqiUDGqOavj07639s0gHni1d6EQ66zKRzUGs4Y6PCgce4FyMOY0695fTRHmMFOgwDMRy TKzL1iXTv3xhUdAIV5oiISmReypL+ZIY9Y3CPgZwv3IT+hW5dEp9ATYKoF8chhofwtXH MxfdSLr9VO72DcpGGkFhHQHV0kosJeEzE0RwXjF7fN/goGQkP5XQVDS0YI/Be07WhKV5 JyKA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=44IiAWJ0srK4F3XBKYUryMqXI15XYoeHFGyp8+dTCmo=; b=HCjwu5cfcLyVSqb/BxEInIwrLuqr6iKQ/5Pf8KWSCroQDmxlwQWYD6iWZIwj63vnfY BGNJ1mfZk9acSgJzTlxYo3fhXR+fF2NHqIPIngSvY91xMDLax/Xu5Irr6S4st1kYqkmm XBU2PGG7T3qEo+K3Qbo4F8Q+4qvMP9AZk1lTsXPcGPXK3LXtxptRvXnKhkM9N5QRyRBk X5TDR3AnAuvlw0MtwYXDjiTr36Vx9yL0vr6vbl/umManQr3ad5HDmSqSqUMmVk8X0GeJ Kvpyo7F8ScBDCES6HHDxyUzDSic/iC7a9Cg4+BwMtj3hYsQ/xnt+8GU38w15hI3gWlNt 0gmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=gSPv05gZ; 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 u1-v6si9716643pgo.114.2018.06.05.07.49.19; Tue, 05 Jun 2018 07:49:34 -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=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=gSPv05gZ; 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 S1752594AbeFEOss (ORCPT + 99 others); Tue, 5 Jun 2018 10:48:48 -0400 Received: from mail-it0-f65.google.com ([209.85.214.65]:33073 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752432AbeFEOsq (ORCPT ); Tue, 5 Jun 2018 10:48:46 -0400 Received: by mail-it0-f65.google.com with SMTP id k17-v6so14707263ita.0 for ; Tue, 05 Jun 2018 07:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=44IiAWJ0srK4F3XBKYUryMqXI15XYoeHFGyp8+dTCmo=; b=gSPv05gZ3ejfeeBw7UpDlVqq9v4mq5vztotk9YDk/I0SBkUpd6aPTPrBIrX2LaSXKc kqF8ky4if9A6BSvMaO11DQTXD/uYSMh5+VBK7Qd5w1rV+Mqfh+KlXMgtRPu+f+MDKo5+ B4/o+9FKG7aVqSdBRcD9awmgFTVifQEpqrF9qy0oreM/0cReclvfAvv6KLoavIXg3Yoz /79FGw2wv9lb0mVoWgwTS5BwONBJMXE5fylV7lqYfkM4Ad5Gf8YiNiA+BGKWZU6tvTAe QgPlBCWWp4pd/nk+C3JRL0A7wVWeCpXfsYXEbdQ0pCTun2e18QJkfUQnBqmzOzj9XzWh 3BBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=44IiAWJ0srK4F3XBKYUryMqXI15XYoeHFGyp8+dTCmo=; b=XKBACZjgEyhSdPRsWOsu46RLtm0MGA3i3YePzWbyop8ddY9nKX8LDJmBPnA7ViEIOB wUyw29v0gje9FNUelEextXcgNnzf5ThK5dO6OlHOxj8830Y9JUPuOEfXT9DkJeoOlQYX RknSguevxauVYXC4tHsQus6nGDNUCCgwdf2JVOpPveCqtxH+AmxSlkcNynshMxcpeFzk H8oJ+J3/xYEKDgha9LZYZqRFfikd5gS7PhA5RRYlJ3WjJ3xI8MPCX01S1x/+qYDPLP/v myoRbgACy6LK5mzr5QAOq6z68WwwIzvILjh4La58g5zhRSeHQEHpg6gO+HGRiSuVdvgV X8Hw== X-Gm-Message-State: APt69E2YxDft3cRoBYibFidUa+fBMyKBXiUDQSccwizDbbxJBwUT+SPJ wAknjE/uwjY6xQkttdwrJ2dOLeWGB/U= X-Received: by 2002:a24:ee4b:: with SMTP id b72-v6mr18839437iti.43.1528210125225; Tue, 05 Jun 2018 07:48:45 -0700 (PDT) Received: from [192.168.1.167] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id i193-v6sm3072450ioi.38.2018.06.05.07.48.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jun 2018 07:48:43 -0700 (PDT) Subject: Re: dm: Use kzalloc for all structs with embedded biosets/mempools To: Mike Snitzer Cc: Kent Overstreet , torvalds@linux-foundation.org, linux-kernel@vger.kernel.org References: <20180605092633.29583-1-kent.overstreet@gmail.com> <20180605144506.GA13100@redhat.com> From: Jens Axboe Message-ID: <7373e0e8-c3b9-2fed-b0a1-88fb4934d82d@kernel.dk> Date: Tue, 5 Jun 2018 08:48:42 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180605144506.GA13100@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/5/18 8:45 AM, Mike Snitzer wrote: > On Tue, Jun 05 2018 at 10:22P -0400, > Jens Axboe wrote: > >> On 6/5/18 3:26 AM, Kent Overstreet wrote: >>> mempool_init()/bioset_init() require that the mempools/biosets be zeroed >>> first; they probably should not _require_ this, but not allocating those >>> structs with kzalloc is a fairly nonsensical thing to do (calling >>> mempool_exit()/bioset_exit() on an uninitialized mempool/bioset is legal >>> and safe, but only works if said memory was zeroed.) >>> >>> Signed-off-by: Kent Overstreet >>> --- >>> >>> Linus, >>> >>> I fucked up majorly on the bioset/mempool conversion - I forgot to check that >>> everything biosets/mempools were being embedded in was actually being zeroed on >>> allocation. Device mapper currently explodes, you'll probably want to apply this >>> patch post haste. >>> >>> I have now done that auditing, for every single conversion - this patch fixes >>> everything I found. There do not seem to be any incorrect ones outside of device >>> mapper... >>> >>> We'll probably want a second patch that either a) changes >>> bioset_init()/mempool_init() to zero the passed in bioset/mempool first, or b) >>> my preference, WARN() or BUG() if they're passed memory that isn't zeroed. >> >> Odd, haven't seen a crash, but probably requires kasan or poisoning to >> trigger anything? Mike's tree also had the changes, since they were based >> on the block tree. >> >> I can queue this up and ship it later today. Mike, you want to review >> this one? > > Yes, looks good. > > From the start of revisiting these changes last week, Kent and I > discussed whether it was safe to call mempool_exit() even if > mempool_init() failed or was never called. He advised that it was so > long as the containing structure was zeroed. But I forgot to audit that > aspect. So this was an oversight by both of us. > > DM core uses kvzalloc_node for struct mapped_device and cache, crypt, > integrity, verity-fec and zoned targets are already using kzalloc as > needed. > > Acked-by: Mike Snitzer Thanks Mike, I'll push this out this morning. -- Jens Axboe