> > > > Looks true to me for the current versions of the code. In fact it is only
> > > > ever called from the initialisation function that I can see so chunks of
> > > > the code could simply go away as well as bits of the comment. Ditto the
> > > > one in drivers/scsi/st.c
> > > >
> > > > Acked-by: Alan Cox <alan@xxxxxxxxxx>
> > > >
> > >
> > > I am sorry I didn't quite understand. You mean it is true that caller
> > > must hold os_scsi_tapes_lock?
> >
> > Sorry - I mean what you claim is true - that the comment is incorrect.
>
> So, I think I'm missing a piece of this: There's no patch in this
> thread (I presume it's lurking somewhere on lkml). Could someone repost
> the proposed patch and copy the tape maintainer: Kai Makisara
> <Kai.Makisara@xxxxxxxxxxx> to get his input?
>
> Thanks,
>
> James
>
>
The patch was in the orginal message. I am resending it now with Makisara CC-ed.
Lin
Removing the wrong comment.
The lock is needed before calling new_tape_buffer(), at least in some cases.
So the comment above new_tape_buffer() is inconsistent with the code and
may mislead developers.
I simply removed the wrong comment, as I am not sure if the lock is required
in all situations. If so, we should add "Caller must hold os_scsi_tapes_lock".
Signed-off-by: Lin Tan <tammy000@xxxxxxxxx>
---
--- a/drivers/scsi/osst.c 2008-09-25 11:53:09.000000000 -0500
+++ b/drivers/scsi/osst.c 2008-09-25 11:59:46.000000000 -0500
@@ -5209,7 +5209,7 @@
/* Memory handling routines */
-/* Try to allocate a new tape buffer skeleton. Caller must not hold os_scsi_tapes_lock */
+/* Try to allocate a new tape buffer skeleton. */
static struct osst_buffer * new_tape_buffer( int from_initialization, int need_dma, int max_sg )
{
int i;
