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 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43B04C3A5A6 for ; Sat, 31 Aug 2019 15:20:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0BCE223405 for ; Sat, 31 Aug 2019 15:20:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567264802; bh=uArJR7nOuUFj0EAGoJ0DqLc4fNAjYzoev/U/aovuGHs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=ac4iPtUsIs3rcV5544BPxJrEhAFGXn0XrkRL/l2FKLzYBfVwzrEfNd7+SNaDsLRzo LFYODsVFJM5DvLMKLfQVrs/52Fuxd14TkbmeXJhwslAWh0Hq2UgG8IPpNvqTrlQa8n crN4f0lsSPh9VLiPPtoi7pOHljaozp10TXD002J4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727905AbfHaPUB (ORCPT ); Sat, 31 Aug 2019 11:20:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:55206 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726354AbfHaPUB (ORCPT ); Sat, 31 Aug 2019 11:20:01 -0400 Received: from localhost (unknown [77.137.115.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 86871217D7; Sat, 31 Aug 2019 15:19:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1567264800; bh=uArJR7nOuUFj0EAGoJ0DqLc4fNAjYzoev/U/aovuGHs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aOv+yThxeVTX8XkrPolWCMUJz8vfeTLIFSmA1HzGWuTU6RKhqz7e+EWalO8RYWzKZ 9gbNbtU5XZcR4Y5RH5lfIdAQvhGkWVRGpJokw6f8ICAuvFlLA6oqRgr30DZXvgu27C FOt3EJcMjfussSK1OQ/vUKZVu7PqLZTUn4YIjHB0= Date: Sat, 31 Aug 2019 18:19:45 +0300 From: Leon Romanovsky To: Doug Ledford Cc: Chuck Lever , Michal Kalderon , linux-rdma Subject: Re: qedr memory leak report Message-ID: <20190831151945.GJ12611@unreal> References: <93085620-9DAA-47A3-ACE1-932F261674AC@oracle.com> <13F323F2-D618-46C3-BE1B-106FD2BEE7F4@oracle.com> <20190831073048.GH12611@unreal> <63286035eb752429fdb651750acf74765caecfe5.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63286035eb752429fdb651750acf74765caecfe5.camel@redhat.com> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Sat, Aug 31, 2019 at 10:33:13AM -0400, Doug Ledford wrote: > On Sat, 2019-08-31 at 10:30 +0300, Leon Romanovsky wrote: > > Doug, > > > > I think that it can be counted as good example why allowing memory > > leaks > > in drivers (HNS) is not so great idea. > > Crashing the machine is worse. The problem with it that you are "punishing" whole subsystem because of some piece of crap which anyway users can't buy. If HNS wants to have memory leaks, they need to do it outside of upstream kernel. In general, if users buy shitty hardware, they need to be ready to have kernel panics too. It works with faulty DRAM where kernel doesn't hide such failures, so don't see any rationale to invent something special for ib_device. Thanks