On 12/08/2017 10:42 AM, Jason Yan wrote: > If the PHY burst too many events, we will alloc a lot of events for the > worker. This may leads to memory exhaustion. > > Dan Williams suggested to shut down the PHY if the events reached the > threshold, because in this case the PHY may have gone into some > erroneous state. Users can re-enable the PHY by sysfs if they want. > > We cannot use the fixed memory pool because if we run out of events, the > shut down event and loss of signal event will lost too. The events still > need to be allocated and processed in this case. > > Suggested-by: Dan Williams <dan.j.willi...@intel.com> > Signed-off-by: Jason Yan <yanai...@huawei.com> > CC: John Garry <john.ga...@huawei.com> > CC: Johannes Thumshirn <jthumsh...@suse.de> > CC: Ewan Milne <emi...@redhat.com> > CC: Christoph Hellwig <h...@lst.de> > CC: Tomas Henzl <the...@redhat.com> > --- > drivers/scsi/libsas/sas_init.c | 33 ++++++++++++++++++++++++++++++++- > drivers/scsi/libsas/sas_phy.c | 27 ++++++++++++++++++++++++++- > include/scsi/libsas.h | 6 ++++++ > 3 files changed, 64 insertions(+), 2 deletions(-) > Well, this still looks a bit error prone; what if the system runs out of memory before the pool is exhausted? (Also a threshold of 1024 events is a bit arbitrary; one might want to adjust that).
Couldn't you allocate two static events always (for shutdown and signal loss), and then use a fixed pool? Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
