openafs-kernel-1.4.8 fails to build with the recent kernel sources. I guess it would fail with both 2.6.27.12 and 2.6.28.1 based kernels. /var/tmp/portage/net-fs/openafs-kernel-1.4.8/work/openafs-1.4.8/src/libafs/MODLOAD-2.6.28-gentoo-r1-MP/osi_vnodeops.c:1794: error: implicit declaration of function ‘__grab_cache_page’
Applying the patch http://www.openafs.org/cgi-bin/wdelta/STABLE14-linux-2629-20090115?diff&f=u and replacing __grab_cache_page with grab_cache_page does the trick.
Pardon my ignorance, but how does one apply the patch? I tried "ebuild ...openafs-kernel... unpack" followed by applying the patch, followed by "ebuild ...openafs-kernel... compile. First off, the unpack step wasn't simply an unpack - it looked as if several preconfiguration steps were run. Then 2 hunks of the patch were rejected - it appears on files that were touched or involved in the preconfiguration steps. Finally the compile failed. I've also tried adding the patch into /usr/portage/net-fs/openafs-kernel/files and rebuilding the digest. This just failed to compile, as well. I saw no sign of the patch being applied. At build time the patches come from /var/tmp/portage/net-fs....work/gentoo/patches, and I see no correlation between the contents of this directory and what's in the /usr/portage/net-fs/openafs-kernel/files directory. This is probably simple, once you know the tricks. Help?
Actually, I tried without the patch and it works. You only have to use grab_cache_page instead of __grab_cache_page. The patch itself is a bit unclean.
Confirmed - the manual fix works for me, as well.
The reason to use grab_cache_page_write_begin instead of plain grab_cache_page is because it will unset the GFP_FS flag when allocating the page, which prevents the allocation code path from potentially recursing back into filesystem code. It probably won't make any difference most of the time, but could cause deadlocks or other problems when under memory pressure. What's "unclean" about the patch? Yes there are a lot more changes, but those are needed for 2.6.29.
(In reply to comment #5) > What's "unclean" about the patch? Yes there are a lot more changes, but those > are needed for 2.6.29. I did not mean the patch contents. The patch has to be corrected a bit (rcs headers) before it can be applied to the source. But still, __grab_cache_page is still there and the compile fails event with the patch applied.
(In reply to comment #6) > I did not mean the patch contents. The patch has to be corrected a bit (rcs > headers) before it can be applied to the source. But still, __grab_cache_page > is still there and the compile fails event with the patch applied. If you grab the diff directly from the RT ticket it won't have those RCS headers. The patch adds new configure tests, so the autoconf files (configure, etc.) need to be regenerated - was this done? (the regen.sh script in the source root can be used)
I have the same error with vanilla-sources-2.6.28.2.
This should be fixed in net-fs/openafs-kernel-1.4.8-r1, tested on amd64 with kernel 2.6.28-gentoo-r1. Please report back if it does not work for you. Thanks for reporting.
