--- drivers/cdrom/cdrom.c.old 2006-08-16 19:04:11.000000000 +0200
+++ drivers/cdrom/cdrom.c 2006-08-16 19:04:51.000000000 +0200
@@ -2455,7 +2455,7 @@
if (tracks.data > 0) return CDS_DATA_1;
/* Policy mode off */
- cdinfo(CD_WARNING,"This disc doesn't have any tracks I recognize!\n");
+ cdinfo(CD_WARNING,"I'm a stupid fuck that will repeat this interesting message while endlessly trying to access the media you just inserted until your CD/DVD burning task is eventually fucked\n");
return CDS_NO_INFO;
}
>I have changed a message that didn't clearly tell the user what was goin
>on...
>
>Please have a look!
It is not April 01, is it?
Jan Engelhardt
--
Jan Engelhardt wrote:
>>I have changed a message that didn't clearly tell the user what was goin
>>on...
>>
>>Please have a look!
>
>
> It is not April 01, is it?
>
>
> Jan Engelhardt
Only when I try to burn a CD...
On Wed, Aug 16, 2006 at 07:26:02PM +0200, Dirk wrote:
> I have changed a message that didn't clearly tell the user what was goin
> on...
>
> Please have a look!
Perhaps the real problem is that some @#$@#$ user space task is
constantly trying to mount the disc while something else is trying to
write to it.
gnome and kde both seem very eager to implement such things. perhaps
there should be a way to prevent any access by such processes while
writing to the disc.
--
Len Sorensen
On Wed, 2006-08-16 at 14:37 -0400, Lennart Sorensen wrote:
> On Wed, Aug 16, 2006 at 07:26:02PM +0200, Dirk wrote:
> > I have changed a message that didn't clearly tell the user what was goin
> > on...
> >
> > Please have a look!
>
> Perhaps the real problem is that some @#$@#$ user space task is
> constantly trying to mount the disc while something else is trying to
> write to it.
>
> gnome and kde both seem very eager to implement such things. perhaps
> there should be a way to prevent any access by such processes while
> writing to the disc.
there is. O_EXCL works for this.
Any sane desktop app and cd burning app use O_EXCL already for this
purpose...
Ar Mer, 2006-08-16 am 19:26 +0200, ysgrifennodd Dirk:
> I have changed a message that didn't clearly tell the user what was goin
> on...
File a gnome/kde/distro bug according whichever pile of garbage you've
got trying to do CD status monitoring and getting it wrong. This isn't a
kernel problem, some idiot user application is asking it continually.
Now there is an argument that the message is debug only but thats
another story.
Alan
Lennart Sorensen wrote:
> On Wed, Aug 16, 2006 at 07:26:02PM +0200, Dirk wrote:
>
>>I have changed a message that didn't clearly tell the user what was goin
>>on...
>>
>>Please have a look!
>
>
> Perhaps the real problem is that some @#$@#$ user space task is
> constantly trying to mount the disc while something else is trying to
> write to it.
>
> gnome and kde both seem very eager to implement such things. perhaps
> there should be a way to prevent any access by such processes while
> writing to the disc.
>
> --
> Len Sorensen
>
>
I still use fvwm1 with _my_ config file unchanged for ~6 years now!!!
But you were right... after i removed some package called "hal"
everything works fine again...
must have been another trojan from the "Ready for the Desktop!" camp...
Dirk
On Wed, 16 Aug 2006 19:26:02 +0200
Dirk <[email protected]> wrote:
> I have changed a message that didn't clearly tell the user what was goin
> on...
>
> Please have a look!
>
> Thank you,
> Dirk
>
>
> --- drivers/cdrom/cdrom.c.old 2006-08-16 19:04:11.000000000 +0200
> +++ drivers/cdrom/cdrom.c 2006-08-16 19:04:51.000000000 +0200
> @@ -2455,7 +2455,7 @@
> if (tracks.data > 0) return CDS_DATA_1;
> /* Policy mode off */
>
> - cdinfo(CD_WARNING,"This disc doesn't have any tracks I recognize!\n");
> + cdinfo(CD_WARNING,"I'm a stupid fuck that will repeat this interesting message while endlessly trying to access the media you just inserted until your CD/DVD burning task is eventually fucked\n");
> return CDS_NO_INFO;
> }
Please keep the code formatted to fit in an 80-column xterm. See
Documentation/CodingStyle. Thanks.
(And you forget the Signed-off-by: line)
>> I have changed a message that didn't clearly tell the user what was goin
>> on...
>>
>> Please have a look!
>>
>> Thank you,
>> Dirk
>>
>>
>> --- drivers/cdrom/cdrom.c.old 2006-08-16 19:04:11.000000000 +0200
>> +++ drivers/cdrom/cdrom.c 2006-08-16 19:04:51.000000000 +0200
>> @@ -2455,7 +2455,7 @@
>> if (tracks.data > 0) return CDS_DATA_1;
>> /* Policy mode off */
>>
>> - cdinfo(CD_WARNING,"This disc doesn't have any tracks I recognize!\n");
>> + cdinfo(CD_WARNING,"I'm a stupid fuck that will repeat this interesting message while endlessly trying to access the media you just inserted until your CD/DVD burning task is eventually fucked\n");
>> return CDS_NO_INFO;
>> }
>
>Please keep the code formatted to fit in an 80-column xterm. See
>Documentation/CodingStyle. Thanks.
>
>(And you forget the Signed-off-by: line)
Before any of this gets ANY chance to get in:
NAK.
Jan Engelhardt
--
On Wed, Aug 16, 2006 at 03:25:09PM -0700, Andrew Morton wrote:
> Please keep the code formatted to fit in an 80-column xterm. See
> Documentation/CodingStyle. Thanks.
>
> (And you forget the Signed-off-by: line)
You made my day :..D
Arjan van de Ven <[email protected]> wrote:
> On Wed, 2006-08-16 at 14:37 -0400, Lennart Sorensen wrote:
>> Perhaps the real problem is that some @#$@#$ user space task is
>> constantly trying to mount the disc while something else is trying to
>> write to it.
>>
>> gnome and kde both seem very eager to implement such things.??perhaps
>> there should be a way to prevent any access by such processes while
>> writing to the disc.
>
> there is. O_EXCL works for this.
> Any sane desktop app and cd burning app use O_EXCL already for this
> purpose...
This was discussed to death:
HAL using O_EXCL will randomly prevent burning/mounting/etc by causing a
race condition, so it can't do that. HAL not using O_EXCL will OTOH succeed
in opening despite of O_EXCL used by the burning process and thereby
prevent burning by opening a busy device. The proposed solution was
introducing O_NONE or O_HARMLESS to prevent side-effects from opening
the device.
This will, however, not prevent other users from maliciously destroying the
CD by not using O_EXCL. Chowning the device is not a real solution, since
users should be able to fusermount the CD.
Maybe it's possible to cache the result and thereby prevent repeated
opening from disturbing the burning process.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
http://david.woodhou.se/why-not-spf.html
On Thu, 2006-08-17 at 14:27 +0200, Bodo Eggert wrote:
> Arjan van de Ven <[email protected]> wrote:
> > On Wed, 2006-08-16 at 14:37 -0400, Lennart Sorensen wrote:
>
> >> Perhaps the real problem is that some @#$@#$ user space task is
> >> constantly trying to mount the disc while something else is trying to
> >> write to it.
> >>
> >> gnome and kde both seem very eager to implement such things. perhaps
> >> there should be a way to prevent any access by such processes while
> >> writing to the disc.
> >
> > there is. O_EXCL works for this.
> > Any sane desktop app and cd burning app use O_EXCL already for this
> > purpose...
>
> This was discussed to death:
>
> HAL using O_EXCL will randomly prevent burning/mounting/etc by causing a
> race condition, so it can't do that.
all burning apps will retry a few times if they get "busy"....
> HAL not using O_EXCL will OTOH succeed
> in opening despite of O_EXCL used by the burning process and thereby
> prevent burning by opening a busy device. The proposed solution was
> introducing O_NONE or O_HARMLESS to prevent side-effects from opening
> the device.
doesn't help, since hal doesn't just open it, but also issues an ioctl
that then goes to the device, and THAT is causing the damage. Not the
open itself.
> This will, however, not prevent other users from maliciously destroying the
> CD by not using O_EXCL.
if the user wants to destroy his own burning cd... then why is it the
kernels job to stop him?
> Maybe it's possible to cache the result and thereby prevent repeated
> opening from disturbing the burning process.
oh I really want to have this ioctl cached, but more so that the kernel
can enforce a reasonable polling interval ;)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Ar Iau, 2006-08-17 am 14:27 +0200, ysgrifennodd Bodo Eggert:
> HAL using O_EXCL will randomly prevent burning/mounting/etc by causing a
> race condition, so it can't do that. HAL not using O_EXCL will OTOH succeed
man 3 sleep
man 2 flock
or in the GUI world I'm firmly assured that the sun shines out of the
arse of dbus for intra desktop communication.
Lots of solutions.
> Maybe it's possible to cache the result and thereby prevent repeated
> opening from disturbing the burning process.
We could certainly add an ioctl for this in the new libata layer. We
couldn't automate it as with pass through commands the kernel doesn't
really know what kind of exclusivity is needed and when.
Not sure its actually useful but its doable.
Alan
On Thu, Aug 17, 2006 at 02:39:11PM +0100, Alan Cox wrote:
> man 3 sleep
> man 2 flock
>
> or in the GUI world I'm firmly assured that the sun shines out of the
> arse of dbus for intra desktop communication.
>
> Lots of solutions.
>
> We could certainly add an ioctl for this in the new libata layer. We
> couldn't automate it as with pass through commands the kernel doesn't
> really know what kind of exclusivity is needed and when.
>
> Not sure its actually useful but its doable.
Why can't O_EXCL mean that the kernel prevents anyone else from issuing
ioctl's to the device? One would think that is the meaning of exlusive.
That way when the burning program opens the device with O_EXCL, no one
else can screw it up while it is open. If it happens to be polled by
hal when the burning program tries to open it, it can just wait and
retry again until it gets it open.
--
Len Sorensen
Lennart Sorensen wrote:
> Why can't O_EXCL mean that the kernel prevents anyone else from issuing
> ioctl's to the device? One would think that is the meaning of exlusive.
> That way when the burning program opens the device with O_EXCL, no one
> else can screw it up while it is open. If it happens to be polled by
> hal when the burning program tries to open it, it can just wait and
> retry again until it gets it open.
Such use of O_EXCL is a weird and non-standard behavior.
Jeff
Ar Iau, 2006-08-17 am 09:23 -0400, ysgrifennodd Lennart Sorensen:
> Why can't O_EXCL mean that the kernel prevents anyone else from issuing
> ioctl's to the device? One would think that is the meaning of exlusive.
If you were designing a new OS from scratch you might want to explore
that semantic as a design idea. I wouldn't recommend it because a lot of
apps will be upset if they issue an ioctl and it mysteriously fails or
hangs.
Issues of this nature require high level synchronization and that
(witness email) is generally done in user space which is the only place
that has transaction level visibility.
Alan
On Thu, Aug 17, 2006 at 09:41:06AM -0400, Jeff Garzik wrote:
> Lennart Sorensen wrote:
> >Why can't O_EXCL mean that the kernel prevents anyone else from issuing
> >ioctl's to the device? One would think that is the meaning of exlusive.
> >That way when the burning program opens the device with O_EXCL, no one
> >else can screw it up while it is open. If it happens to be polled by
> >hal when the burning program tries to open it, it can just wait and
> >retry again until it gets it open.
>
> Such use of O_EXCL is a weird and non-standard behavior.
So what method exists for opening a file/device an guaranteeing that
nothing else can do anything to it?
Looking an man 2 open, I can't even see any way O_EXCL even has a normal
meaning for a device, so how much more "weird and non-standard" would it
be to have it control exclusive access to a device? It appears it is
only supposed to have a meaning for creating files.
--
Len Sorensen
On Thu, Aug 17, 2006 at 02:48:50PM +0100, Alan Cox wrote:
> Ar Iau, 2006-08-17 am 09:23 -0400, ysgrifennodd Lennart Sorensen:
> > Why can't O_EXCL mean that the kernel prevents anyone else from issuing
> > ioctl's to the device? One would think that is the meaning of exlusive.
>
> If you were designing a new OS from scratch you might want to explore
> that semantic as a design idea. I wouldn't recommend it because a lot of
> apps will be upset if they issue an ioctl and it mysteriously fails or
> hangs.
I think hal should get an error when it tries to open the cdrom device
when the burning application is using it. It shouldn't even get a
chance to issue an ioctl. I was assuming hal doesn't keep the cdrom
device open at all times (if it does, well that would be stupid).
> Issues of this nature require high level synchronization and that
> (witness email) is generally done in user space which is the only place
> that has transaction level visibility.
Hmm, so how does one tell hal to go to hell and leave the cdrom device
alone at all times (other than totally disabling hal). Who the heck
wants all that stupid auto crap anyhow. :)
--
Len Sorensen
On Thu, 2006-08-17 at 10:36 -0400, Lennart Sorensen wrote:
> On Thu, Aug 17, 2006 at 02:48:50PM +0100, Alan Cox wrote:
> > Ar Iau, 2006-08-17 am 09:23 -0400, ysgrifennodd Lennart Sorensen:
> > > Why can't O_EXCL mean that the kernel prevents anyone else from issuing
> > > ioctl's to the device? One would think that is the meaning of exlusive.
> >
> > If you were designing a new OS from scratch you might want to explore
> > that semantic as a design idea. I wouldn't recommend it because a lot of
> > apps will be upset if they issue an ioctl and it mysteriously fails or
> > hangs.
>
> I think hal should get an error when it tries to open the cdrom device
> when the burning application is using it.
this is what O_EXCL is for ;)
> Hmm, so how does one tell hal to go to hell and leave the cdrom device
> alone at all times (other than totally disabling hal).
make sure hal uses O_EXCL, and if not, beat up the hal guys about it ;)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Lennart Sorensen wrote:
> On Thu, Aug 17, 2006 at 09:41:06AM -0400, Jeff Garzik wrote:
>
>> Lennart Sorensen wrote:
>>
>>> Why can't O_EXCL mean that the kernel prevents anyone else from issuing
>>> ioctl's to the device? One would think that is the meaning of exlusive.
>>> That way when the burning program opens the device with O_EXCL, no one
>>> else can screw it up while it is open. If it happens to be polled by
>>> hal when the burning program tries to open it, it can just wait and
>>> retry again until it gets it open.
>>>
>> Such use of O_EXCL is a weird and non-standard behavior.
>>
>
> So what method exists for opening a file/device an guaranteeing that
> nothing else can do anything to it?
>
None on the file level I hope, for it will surely get abused.
Windows have exclusive open for example, and there acrobat reader
locks the pdf file it views, so you can't make a new version without
killing acrobat first. (And then you have to restart it to
view the new file.) Stupid in the extreme. Fortunately, acrobat can't
do that on linux where there is no (easy) opportunity to do so.
There are many other examples - backup sw can't read files that
happens to be opened exclusive by some process.
I guess this particular case could be solved by fixing the cdrom
driver like this:
Whenever the device is opened for writing (i.e. someone is
burning a CD/DVD), then reject the probing ioctls HAL uses.
Or just make the device exclusive while burning. Restore
normal operation as soon as the burn ends. There is no
use for reading the device during a burn anyway - a special case
for CD/DVD writers.
Helge Hafting
Ar Iau, 2006-08-17 am 10:36 -0400, ysgrifennodd Lennart Sorensen:
> I think hal should get an error when it tries to open the cdrom device
> when the burning application is using it. It shouldn't even get a
If it uses O_EXCL it will find the device busy assuming both parties use
O_EXCL properly.
> chance to issue an ioctl. I was assuming hal doesn't keep the cdrom
> device open at all times (if it does, well that would be stupid).
Indeed but this is HAL so I suggest you strace it first 8)
On Thu, 17 Aug 2006, Arjan van de Ven wrote:
> On Thu, 2006-08-17 at 14:27 +0200, Bodo Eggert wrote:
> > This will, however, not prevent other users from maliciously destroying the
> > CD by not using O_EXCL.
>
> if the user wants to destroy his own burning cd... then why is it the
> kernels job to stop him?
It's user a destroying the CD of user b (e.g. because he erroneously
believes his CD with the plain tar archive is in the burner, or because
he's simply malicious).
--
"Of course, as admin, I can read all your email. But I am not THAT bored!"
-- unknown author in comp.unix.aix
On Thu, 17 Aug 2006, Helge Hafting wrote:
> None on the file level I hope, for it will surely get abused.
> Windows have exclusive open for example, and there acrobat reader
> locks the pdf file it views, so you can't make a new version without
> killing acrobat first. (And then you have to restart it to
> view the new file.) Stupid in the extreme. Fortunately, acrobat can't
> do that on linux where there is no (easy) opportunity to do so.
The default open mode on network-aware DOS-systems will automatically
aquire an exclusive lock in order to maintain DOS 2.0 compatibility,
and the filename is part of the file's metadata. Windows seems to have
kept this behaviour.
--
"Bravery is being the only one who knows you're afraid."
-David Hackworth
On Fri, 2006-08-18 at 14:31 +0200, Bodo Eggert wrote:
> On Thu, 17 Aug 2006, Arjan van de Ven wrote:
> > On Thu, 2006-08-17 at 14:27 +0200, Bodo Eggert wrote:
>
> > > This will, however, not prevent other users from maliciously destroying the
> > > CD by not using O_EXCL.
> >
> > if the user wants to destroy his own burning cd... then why is it the
> > kernels job to stop him?
>
> It's user a destroying the CD of user b (e.g. because he erroneously
> believes his CD with the plain tar archive is in the burner, or because
> he's simply malicious).
that would only be if both A and B have write access to the same device,
at which point they can destroy eachother anyway
(nothing stops user B from issuing a blank command to the cdrw the
milisecond A is done)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Ar Gwe, 2006-08-18 am 14:31 +0200, ysgrifennodd Bodo Eggert:
> It's user a destroying the CD of user b (e.g. because he erroneously
> believes his CD with the plain tar archive is in the burner, or because
> he's simply malicious).
Thats why you need revoke().
Alan
Lennart Sorensen wrote:
>
> Hmm, so how does one tell hal to go to hell and leave the cdrom device
> alone at all times (other than totally disabling hal).
AFAIK many drivers allow multiple opening of device files. If programs do not
honor any kind of locking (advisory, O_EXCL) use mandatory locking (DOS 2.0
compatibility, no problems ;)
> Who the heck wants all that stupid auto crap anyhow. :)
>
Yea. But see RH managers on its videos, happy about usb sticks being plugged
and worked, he-he:
<http://www.redhat.com/v/magazine/mov/005_BehindScenes_RHEL4.mov>.
I've just installed debian-gnu and got all that
cpufrequtils, powermgmt, acpiutils installed on amd64 laptop
while i just need:
,-
|modprobe powernow-k8
|modprobe cpufreq_ondemand
|echo ondemand >scailing_governor
`-
Anyway long, almost 10 years, way to win95 and win98 is never ending ;D
--
-o--=O`C /. .\ (???) (+) /o o\
#oo'L O o | o.
<___=E M ^-- | (you're barking up the wrong tree) =--'
On Sat, Aug 19, 2006 at 07:52:25PM +0200, Oleg Verych wrote:
> AFAIK many drivers allow multiple opening of device files. If programs do
> not
> honor any kind of locking (advisory, O_EXCL) use mandatory locking (DOS 2.0
> compatibility, no problems ;)
>
> Yea. But see RH managers on its videos, happy about usb sticks being plugged
> and worked, he-he:
> <http://www.redhat.com/v/magazine/mov/005_BehindScenes_RHEL4.mov>.
>
> I've just installed debian-gnu and got all that
> cpufrequtils, powermgmt, acpiutils installed on amd64 laptop
> while i just need:
> ,-
> |modprobe powernow-k8
> |modprobe cpufreq_ondemand
> |echo ondemand >scailing_governor
> `-
> Anyway long, almost 10 years, way to win95 and win98 is never ending ;D
Don't worry, NT4 didn't do that either, you had to wait for windows 2000
before you got a decent kernel and all the power management and hotplug
stuff.
--
Len Sorensen