linux-kernel - Re: [SCSI] fix media change events for polled devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47E41DD3.2040602@garzik.org>
Date:	Fri, 21 Mar 2008 16:42:59 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Kay Sievers <kay.sievers@...y.org>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-scsi@...r.kernel.org
Subject: Re: [SCSI] fix media change events for polled devices

Kay Sievers wrote:
> On Fri, 2008-03-21 at 13:12 -0400, Jeff Garzik wrote:
>> Linux Kernel Mailing List wrote:
>>>     [SCSI] fix media change events for polled devices
>>>     
>>>     Commit:
>>>       a341cd0f (SCSI: add asynchronous event notification API)
>>>     breaks:
>>>       285e9670 (sr,sd: send media state change modification events)
>>>     by introducing an event filter, which is removed here, to make
>>>     events, we are depending on, happen again.
>>
>> By simply reading the code history, it is trivial to verify that this 
>> description is false:
>>
>> Commit 285e9670 depends on a341cd0f, so by definition it is 285e9670 -- 
>> or rather the incomplete update of your original patch that resulted in 
>> 285e9670 -- that is broken.
> 
> It worked fine with Kristen's patches, and that's where it is coming
> from from.

Neither her patches nor yours went upstream verbatim at version one. 
You need to look at what happens upstream, not what happened in your 
private testing six months ago.


> You mean the read-only sysfs attribute? :)

I mean the attribute with both 'show' (read) and 'store' (write) 
functions.  The perms do need to change, thanks for noticing that bug.


> 
>> Did anyone bother to read any code at all?
>>
>> When 285e9670 was updated for the scsi_evt_* interface, it should have 
>> initialized the supported_events mask.
>>
>> And that is the fix -- initialize supported_events according to sr/sd's 
>> needs, and revert this change (4d1566ed2100d074ccc654e5cf2e44cdea3a01d0) 
>> as obviously broken.
> 
> You mean adding a new flag? As every device will "support" these events.

Does every device attached to every controller wish to fire these events?

If so, then that wants new flag, yes.

	Jeff


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/