On Thu, 2016-07-28 at 21:23 -0400, Martin K. Petersen wrote:
> > > > > > "Calvin" == Calvin Owens writes:
>
> > > Any thoughts? Squinting at this more it still seems racy, but a
> > > narrow race is surely better than just blatantly freeing
> > > everything
> > > while the file is still exposed i
> "Calvin" == Calvin Owens writes:
>> Any thoughts? Squinting at this more it still seems racy, but a
>> narrow race is surely better than just blatantly freeing everything
>> while the file is still exposed in /sys? Is there a better way you'd
>> prefer I accomplish this?
>>
>> (I have boxe
On 06/15/2016 01:24 PM, Calvin Owens wrote:
On Thursday 06/02 at 15:50 -0700, Calvin Owens wrote:
On 05/13/2016 01:28 PM, Calvin Owens wrote:
Currently we free the resources backing the enclosure device before we
call device_unregister(). This is racy: during rmmod of low-level SCSI
drivers tha
On Thursday 06/02 at 15:50 -0700, Calvin Owens wrote:
> On 05/13/2016 01:28 PM, Calvin Owens wrote:
> > Currently we free the resources backing the enclosure device before we
> > call device_unregister(). This is racy: during rmmod of low-level SCSI
> > drivers that hook into enclosure, we end up w
On 05/13/2016 01:28 PM, Calvin Owens wrote:
Currently we free the resources backing the enclosure device before we
call device_unregister(). This is racy: during rmmod of low-level SCSI
drivers that hook into enclosure, we end up with a small window of time
during which writing to /sys can OOPS.
Currently we free the resources backing the enclosure device before we
call device_unregister(). This is racy: during rmmod of low-level SCSI
drivers that hook into enclosure, we end up with a small window of time
during which writing to /sys can OOPS. Example trace with mpt3sas:
general protect
6 matches
Mail list logo