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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080626170513.GE23386@duck.suse.cz>
Date:	Thu, 26 Jun 2008 19:05:14 +0200
From:	Jan Kara <jack@...e.cz>
To:	Jens Axboe <axboe@...nel.dk>
Cc:	Michael Buesch <mb@...sch.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Oops when using growisofs

On Wed 25-06-08 11:46:29, Michael Buesch wrote:
> On Wednesday 25 June 2008 11:37:00 Jan Kara wrote:
> > > Yeah the IO error is the trigger.
> > > I noticed that it had obvious troubles accessing the DVD that was in the drive.
> > > It sweeped over it for several seconds, then hung the system for 2 or 3 seconds
> > > and then oopsed. But after that everything continued to work as usual.
> > > (Except kded of course)
> >   Hmm, by "accessing" do you mean that you've mounted the burned DVD and when
> > browsing it the IO error and the oops occured or that IO error happened
> > when burning? It is important because in the first case i_blkbits would be
> > taken from some ISOFS inode desribing some file while in the second case
> > i_blkbits are from the inode of the device...
> I don't know. kded, which caused the oops, is always running. It is a KDE daemon
> that polls device state and so on. So yeah, it might have accessed the drive
> while growisofs was writing to it.
> 
> However with "accessing" I mean the DVD drive motor was spinning up and down
> and the laser lens was moving like crazy. The sound that happens, if you put
> a completely scratched DVD into the drive and it is unable to make sense of it.
> However, this was not scratched. It was a new DVD with one session on it that
> I just burnt 5 minutes before that. So I wanted to append another session to it
> and it crashed and resulted in IO errors in growisofs.
  I've been looking into this problem for some time. The only way how I see
blocksize can be set so big is in cdrom_read_capacity() in
drivers/ide/ide-cd.c. That basically blindly fills in queue->hardsect_size with what
the drive returns and this can propagate in bd_set_size() to i_blkbits.
Jens, do you think that is possible? Shouldn't ide_cd_read_toc() do some
sanity checks of the blocksize returned?

										Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ