kernel unaligned access on sparc64

[cross]

System information

Type	Version/Name
Distribution Name	debian
Distribution Version	10.0 / sid
Linux Kernel	4.16.12-1
Architecture	sparc64
ZFS Version	0.7.9-3
SPL Version	0.7.9-3

Describe the problem you're observing

When accessing nfs filesystems on my sparc64 Debian system, I see periodic messages from the kernel:

[774881.959161] Kernel unaligned access at TPC[1206effc] sa_build_layouts+0x47c/0xc20 [zfs]
[774882.208801] Kernel unaligned access at TPC[1206efe0] sa_build_layouts+0x460/0xc20 [zfs]

Describe how to reproduce the problem

Install ZFS on a sparc64 Linux system, perform reads/writes on ZFS filesystems.

Include any warning/errors/backtraces from the system logs

[774881.959161] Kernel unaligned access at TPC[1206effc] sa_build_layouts+0x47c/0xc20 [zfs]
[774882.208801] Kernel unaligned access at TPC[1206efe0] sa_build_layouts+0x460/0xc20 [zfs]

[cross]

With advice from Andreas Dilger on the zfs-devel mailing list, I opened this ticket. Also, his suggestion to work around this problem was successful for me. The following change to and near SA_COPY_DATA in module/zfs/sa.c avoids the unaligned access for me in my testing:

#if defined(__ARM_FEATURE_UNALIGNED) || defined(__i386) || defined(__amd64)    
# define UNALIGNED_POINTERS_PERMITTED 1                                        
#else                                                                          
# define UNALIGNED_POINTERS_PERMITTED 0                                        
#endif

#define SA_COPY_DATA(f, s, t, l) \                                             
        { \                                                                     
                if (UNALIGNED_POINTERS_PERMITTED && f == NULL) { \              
                        if (l == 8) { \                                         
                                *(uint64_t *)t = *(uint64_t *)s; \              
                        } else if (l == 16) { \                                 
                                *(uint64_t *)t = *(uint64_t *)s; \              
                                *(uint64_t *)((uintptr_t)t + 8) = \             
                                    *(uint64_t *)((uintptr_t)s + 8); \          
                        } else { \                                              
                                bcopy(s, t, l); \                               
                        } \                                                     
                } else \                                                        
                        sa_copy_data(f, s, t, l); \                             
        }                                                                       

The post from the thread where this was discussed, including Andreas' note that the above is not likely the best place for this fix, is http://list.zfsonlinux.org/pipermail/zfs-devel/2018-June/000169.html.

[behlendorf]

@cross and @adilger thanks for doing all the leg work on this. I've opened #7684 with a proposed fix for review which relies on CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS as defined by the kernel to determine if unaligned accesses should be allowed. @cross it would be great if you could verify the patch on your system since I don't have easy access to any sparc hardware these days.

[cross]

@behlendorf can do. I'm rebuilding an unmodified source of Debian's zfs-0.7.9 now, will install that and confirm I can reproduce the original error. Then I'll apply the diff in that commit and verify it's gone away. Will report back here when I have results. Hopefully this weekend.

[cross]

I have applied the patch in that commit, at least most of it. Given Debian packaging and DKMS and other things, it didn't apply whole-hog. But, three out of four files patched in multiple trees, and certainly the piece to modules/zfs/sa.c was enough to remove the unaligned access warnings for me on my sparc. If you've tested it on other platforms which should have HAVE_EFFICIENT_UNALIGNED_ACCESS, then it should be fully tested now.

[behlendorf]

@cross thanks for making to time to get this verified this on sparc. I'll get this merged since it has been tested on the other relevant platforms.