> >In the code, we see:
> >
> >if (unlikely(size & (bdev_hardsect_size(bdev)-1) ||
> > (size < 512 || size > PAGE_SIZE))) {
> >
> >This is where __getblk_slow, and thus, __getblk fails, and it does not
> >seem to be due to any memory management bug.
>
> This is a filesystem bug --- filesystem should set it's blocksize with
> sb_set_blocksize (and refuse to mount if the device doesn't support it)
> before using it in requests.
>
> Mikulas
>
No doubt about it.
But in case it does not, or in the case the value gets corrupted after
the check but before the call, it will lead some code to dereferencing a
NULL pointer, and making the whole system crash for a silly thing.
So, for me, checking for the value after the call to __getblk does seem
the right approach.
--
=====================================
Glauber de Oliveira Costa
IBM Linux Technology Center - Brazil
[email protected]
=====================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
