svn commit: r247116 - in head/sys: fs/nfs fs/nfsclient kern nfsclient sys tools

[Alan Cox]

On 02/26/2013 01:27, Andrew Turner wrote:
> On Mon, 25 Feb 2013 15:00:41 -0600
> Alan Cox <alc at rice.edu> wrote:
>
>> On Feb 25, 2013, at 4:36 AM, Andrew Turner wrote:
>>
>>> On Mon, 25 Feb 2013 10:50:19 +0200
>>> Konstantin Belousov <kostikbel at gmail.com> wrote:
>>>
>>>> On Mon, Feb 25, 2013 at 08:13:13PM +1300, Andrew Turner wrote:
>>>>> On Thu, 21 Feb 2013 19:02:50 +0000 (UTC)
>>>>> John Baldwin <jhb at FreeBSD.org> wrote:
>>>>>
>>>>>> Author: jhb
>>>>>> Date: Thu Feb 21 19:02:50 2013
>>>>>> New Revision: 247116
>>>>>> URL: http://svnweb.freebsd.org/changeset/base/247116
>>>>>>
>>>>>> Log:
>>>>>>  Further refine the handling of stop signals in the NFS client.
>>>>>> The changes in r246417 were incomplete as they did not add
>>>>>> explicit calls to sigdeferstop() around all the places that
>>>>>> previously passed SBDRY to _sleep().  In addition,
>>>>>> nfs_getcacheblk() could trigger a write RPC from getblk()
>>>>>> resulting in sigdeferstop() recursing. Rather than manually
>>>>>> deferring stop signals in specific places, change the VFS_*() and
>>>>>> VOP_*() methods to defer stop signals for filesystems which
>>>>>> request this behavior via a new VFCF_SBDRY flag. Note that this
>>>>>> has to be a VFC flag rather than a MNTK flag so that it works
>>>>>> properly with VFS_MOUNT() when the mount is not yet fully
>>>>>> constructed.  For now, only the NFS clients are set this new flag
>>>>>> in VFS_SET(). A few other related changes:
>>>>>>  - Add an assertion to ensure that TDF_SBDRY doesn't leak to
>>>>>> userland.
>>>>>>  - When a lookup request uses VOP_READLINK() to follow a symlink,
>>>>>> mark the request as being on behalf of the thread performing the
>>>>>> lookup (cnp_thread) rather than using a NULL thread pointer.
>>>>>> This causes NFS to properly handle signals during this VOP on an
>>>>>> interruptible mount.
>>>>>>
>>>>>>  PR:		kern/176179
>>>>>>  Reported by:	Russell Cattelan (sigdeferstop() recursion)
>>>>>>  Reviewed by:	kib
>>>>>>  MFC after:	1 month
>>>>> This change is causing init to crash for me on armv6. I'm
>>>>> netbooting a PandaBoard and it appears init is receiving a SIGABRT
>>>>> before it gets into main().
>>>>>
>>>>> Do you have any idea where I could look to track down why it is
>>>>> doing this?
>>>> It is weird. SIGABRT sent by the kernel usually means that
>>>> execve(2) already destroyed the previous address space of the
>>>> process, but the new image cannot be activated, most likely due to
>>>> image format error discovered too late, or resource shortage.
>>>>
>>>> Could it be that some NFS RPC fails after the patch, but I cannot
>>>> imagine why. You would need to track this. Also, verify that the
>>>> init binary is correct.
>>>>
>>>> I tried amd64 netboot, and it worked fine.
>>> It looks like this change is not the issue, it just changed the
>>> symptom enough for me to not realise I was seeing an issue where
>>> it would crash the kernel before. I reinstated this change but only
>>> allowed the kernel to access half the memory and it booted
>>> correctly.
>>>
>>> The real issue appears to be related to something in the vm layer
>>> not working on ARM boards with too much memory (somewhere between
>>> 512MiB and 1GiB).
>>
>> The recently introduced auto-sizing and cap may be too optimistic.
>> In fact, they are greater than what we allow on 32-bit x86 and 32-bit
>> MIPS.  Try the following.
>>
>> Index: arm/include/vmparam.h
>> ===================================================================
>> --- arm/include/vmparam.h	(revision 247249)
>> +++ arm/include/vmparam.h	(working copy)
>> @@ -142,15 +142,15 @@
>>  #define VM_KMEM_SIZE		(12*1024*1024)
>>  #endif
>>  #ifndef VM_KMEM_SIZE_SCALE
>> -#define VM_KMEM_SIZE_SCALE	(2)
>> +#define VM_KMEM_SIZE_SCALE	(3)
>>  #endif
>>  
>>  /*
>> - * Ceiling on the size of the kmem submap: 60% of the kernel map.
>> + * Ceiling on the size of the kmem submap: 40% of the kernel map.
>>   */
>>  #ifndef VM_KMEM_SIZE_MAX
>>  #define	VM_KMEM_SIZE_MAX	((vm_max_kernel_address - \
>> -    VM_MIN_KERNEL_ADDRESS + 1) * 3 / 5)
>> +    VM_MIN_KERNEL_ADDRESS + 1) * 2 / 5)
>>  #endif
>>  
>>  #define MAXTSIZ 	(16*1024*1024)
>>
> This patch fixes the boot for me. Is it likely we will see similar
> issues with boards with more memory with this? I know of ARM boards
> with 2GiB of ram, and I would expect to see some with more soon.
>

The kmem submap should be fine, but other things might become a problem.

What do "sysctl -x vm.min_kernel_address" and "sysctl -x
vm.max_kernel_address" report on your machine?

Alan