svn commit: r206129 - head/sys/kern

[Peter Jeremy]

On 2010-Apr-05 00:27:42 +0300, Kostik Belousov <kostikbel at gmail.com> wrote:
>On Mon, Apr 05, 2010 at 12:11:06AM +0300, Andriy Gapon wrote:
>> on 05/04/2010 00:03 Peter Jeremy said the following:
>> > On 2010-Apr-03 08:39:00 +0000, Andriy Gapon <avg at FreeBSD.org> wrote:
>> >>  vn_stat: take into account va_blocksize when setting st_blksize
...
>> > I haven't verified it but, based on a quick look at the change, I
>> > suspect this will trigger the problem in bin/144446.  Quick summary:
>> > db(3) has restrictions on its internal bucket size but initializes it
>> > from st_blksize with no sanity checking and ZFS can report blocksizes
>> > outside the allowed bucket size range for db(3).
>> 
>> Thank you for pointing this out.
>> If no one objects or provides a better patch, I will commit yours.
>
>I do not think this is very satisfying solution. Pre-patched libc
>still suffer from the problem. You cannot run stable/8 libc on this
>kernel.

Firstly, has someone with a post-r206129 kernel verified that it
does actually trigger the issue I reported in bin/144446?  I'm not
in a position to do so easily and it's possible that the problem
is masked elsewhere.

Also, Kostik's comment is a slight exaggeration:  You can't create a
db(3) database from scratch in a ZFS filesystem using db(3) defaults.
Note that as of now, it's exactly the same situation as running
-current libc with a post-r206129 kernel.

-current is expected to include occasions of bumpiness so I don't see
this as an immediate reason to revert r206129 - though if buildworld
or installworld are affected, it at least needs a heads-up.  OTOH, I
think some care needs to taken over any MFC of this change.  At the
very least, the db(3) problem needs to be fixed and there probably
needs to be an extended shakedown of r206129 to ensure that there
aren't any other similar nasties lurking elsewhere.

The problem I reported in bin/144446 is a bug in a userland utility
and IMHO, it's not the kernel's responsibility to work around userland
bugs.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20100404/fc1b3642/attachment.pgp