From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mikulas Patocka Subject: Re: dm-mpath: do not change SCSI device handler Date: Thu, 4 Apr 2013 11:13:06 -0400 (EDT) Message-ID: References: <515D21EB.8010701@suse.de> <20130404122408.GA9996@redhat.com> <20130404131631.GA10208@redhat.com> <20130404142048.GB10208@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130404142048.GB10208@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Mike Snitzer Cc: dm-devel@redhat.com List-Id: dm-devel.ids On Thu, 4 Apr 2013, Mike Snitzer wrote: > I'm suggesting that switching the scsi_dh is not something that will be > done on a system that is suffering from serious memory contention. > > But I think we need to get back to analyzing the scsi_dh change you > mentioned before with tracking counts, etc. When I look at the code, I see module_put(THIS_MODULE) in all scsi device handlers. Moreover, there are many 'module_put(THIS_MODULE)' over the whole kernel. It seems buggy, because when the function module_put returns, reschedule happens, module is unloaded, the process that called module_put(THIS_MODULE) is scheduled back again, crash happens because we are running a code that no longer exists. Is it a bug or is there some trick that prevents the kernel from crashing in this scenario? Mikulas