Re: Occasional truncated scan results

[Johannes Berg <johannes@sipsolutions.net>]

On Tue, 2012-02-28 at 16:15 +0100, Ronald Wahl wrote:

> >> Currently I implemented a heuristic that checks if some minimum space
> >> (currently 256 bytes) is still free _after_ adding a BSS and otherwise
> >> return -E2BIG so the user space can provide a larger buffer but this is
> >> a crappy hack.
> >>
> >> Can the code be changed in some way to more reliably detect if some data
> >> did not fit into the buffer and report this to user space?
> >
> > Unfortunately not. The maximum buffer size userspace can provide is
> > limited to 64k. In busy environments, this size can be exceeded. As a
> > result, if we do this, you can't get *any* scan results in such
> > environments. I believe the current code is almost the best we can do
> > for wireless extensions, but it may be possible to implement never
> > truncating a single BSS entry.
> 
> My problem is not that the scan results are larger than 64k. The user 
> space is coded so that it provides a small buffer that is doubled in 
> size until the data fits into the buffer. But the kernel code does not 
> always detect the case that the buffer is almost full and just starts 
> skipping some data without notifying user space with E2BIG.

Ok. Yes, this could be fixed by making sure that a single BSS is
atomically written or not written -- probably simply by rolling back at
the end of the function if it didn't fit and returning an error etc. If
you wanted to work on this, I'd review & accept the patch, but I have no
intention whatsoever to do this myself :-)

johannes