Hi,
I have hit a problem with the /proc interface for the aic7xxx driver.
From looking at the code, it seems to be a long-standing problem
which has only recently started manifesting symptoms (though maybe I
just haven't noticed it before).
The symptom is that sometimes,
cat /proc/scsi/aic7xxx/0
returns pure garbage.
The way the driver code in drivers/scsi/aic7xxx_proc.c works, is that
it doesn't use the passed buffer at all, but allocated it's own
buffer and encodes the data into that. It then returns a pointer to
an apropriate offset in this buffer in the "char **start" parameter.
The way that proc_file_read in fs/proc/generic.c handles this start
value, is that if it is greater than the passed "page", it is
believed, and if it is less than the passed page, it is assumed to be
an increment to add to the ppos (file position pointer). This is, as
the code admits, a hack.
So if the page allocated for proc_read_file happens to be later in
memory than the buffer allocted to aic7xxx_proc_info, then I get
garbage. This seems to happen in practice about half of the time.
I see three ways to fix this:
1/ change aic7xxx_proc_info to use the supplied buffer instead of
it's own. I gather this is how most drivers work. I don't
really feel up to that at the moment.
2/ Get rid of the 'hack' in proc_file_read - and break anything
that depends on it.... probably not a good idea.
3/ "tune" the hack a bit so that it believes "start" to be a
pointer unless it is less than, say, 65536. That would
probably be safe, and would certainly be easy, but would be
even more of a hack.
Any comments, advice, or offers to do "1" most welcome.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
