Bug#1067829: Fails to build on arm{el,hf} with 64bit time_t: export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} [-We
> On Apr 6, 2024, at 3:15 PM, Salvatore Bonaccorso wrote:
>
> Hi Chuck, hi Steve,
>
> In Debian, as you might have heard there is a 64bit time_t
> transition[1] ongoing affecting the armel and armhf architectures.
> While doing so, nfs-utils was found to fail to build for those
> architectures after the switch, reported in Debian as [2]. Vladimir
> Petko from Ubuntu has as well filled it in [3].
>
> [1]: https://lists.debian.org/debian-devel-announce/2024/02/msg5.html
> [2]: https://bugs.debian.org/1067829
> [3]: https://bugzilla.kernel.org/show_bug.cgi?id=218540
>
> The report is full-quoted below.
>
> Vladimir Petko has created a patch in the bugzilla which I'm attaching
> here as well. If this is not an acceptable format due to missing
> Signed-off's I'm attaching a variant with a Suggested-by for Vladimir
> to properly credit the patch origin.
>
> Let me know if that works. I changed it slightly and only casting to
> long long, and made it almost checkpatch clean.
I suppose strftime(3) might be nicer, but this works.
Reviewed-by: Chuck Lever mailto:chuck.le...@oracle.com>>
> Regards,
> Salvatore
>
> - Forwarded message from Sebastian Ramacher -
>
> From: Sebastian Ramacher
> Resent-From: Sebastian Ramacher
> Reply-To: Sebastian Ramacher , 1067...@bugs.debian.org
> Date: Wed, 27 Mar 2024 11:02:25 +0100
> To: Debian Bug Tracking System
> Subject: Bug#1067829: nfs-utils: FTBFS on arm{el,hf}: export-cache.c:110:51:
> error: format ‘%ld’ expects argument of
> type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’}
> [-Werror=format=]
> Delivered-To: sub...@bugs.debian.org
> Message-ID:
>
> Source: nfs-utils
> Version: 1:2.6.4-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: sramac...@debian.org
>
> https://buildd.debian.org/status/fetch.php?pkg=nfs-utils=armel=1%3A2.6.4-3%2Bb2=1711452552=0
>
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../support/include
> -I/usr/include/tirpc -I/usr/include/libxml2 -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2
> -D_GNU_SOURCE -pipe -Wall -Wextra -Werror=strict-prototypes
> -Werror=missing-prototypes -Werror=missing-declarations -Werror=format=2
> -Werror=undef -Werror=missing-include-dirs -Werror=strict-aliasing=2
> -Werror=init-self -Werror=implicit-function-declaration -Werror=return-type
> -Werror=switch -Werror=overflow -Werror=parentheses -Werror=aggregate-return
> -Werror=unused-result -fno-strict-aliasing -Werror=format-overflow=2
> -Werror=int-conversion -Werror=incompatible-pointer-types
> -Werror=misleading-indentation -Wno-cast-function-type -g -O2
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -c xml.c -fPIC -DPIC -o .libs/xml.o
> export-cache.c: In function ‘junction_flush_exports_cache’:
> export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long
> int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
> 110 | snprintf(flushtime, sizeof(flushtime), "%ld\n", now);
> | ~~^ ~~~
> | | |
> | | time_t {aka
> long long int}
> | long int
> | %lld
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../support/include
> -I/usr/include/tirpc -I/usr/include/libxml2 -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2
> -D_GNU_SOURCE -pipe -Wall -Wextra -Werror=strict-prototypes
> -Werror=missing-prototypes -Werror=missing-declarations -Werror=format=2
> -Werror=undef -Werror=missing-include-dirs -Werror=strict-aliasing=2
> -Werror=init-self -Werror=implicit-function-declaration -Werror=return-type
> -Werror=switch -Werror=overflow -Werror=parentheses -Werror=aggregate-return
> -Werror=unused-result -fno-strict-aliasing -Werror=format-overflow=2
> -Werror=int-conversion -Werror=incompatible-pointer-types
> -Werror=misleading-indentation -Wno-cast-function-type -g -O2
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -c display.c -o display.o >/dev/null 2>&1
> cc1: some warnings being treated as errors
> make[3]: *** [Makefile:489: export-cache.lo] Error 1
> make[3]: *** Waiting for unfinished jobs
>
> Cheers
> --
> Sebastian Ramacher
>
> - End forwarded message -
> <0001-junction-export-cache-cast-to-a-type-with-a-known-si.patch>
--
Chuck Lever
Bug#940821: NFS Caching broken in 4.19.37
> On Feb 20, 2021, at 3:13 PM, Anton Ivanov > wrote: > > On 20/02/2021 20:04, Salvatore Bonaccorso wrote: >> Hi, >> >> On Mon, Jul 08, 2019 at 07:19:54PM +0100, Anton Ivanov wrote: >>> Hi list, >>> >>> NFS caching appears broken in 4.19.37. >>> >>> The more cores/threads the easier to reproduce. Tested with identical >>> results on Ryzen 1600 and 1600X. >>> >>> 1. Mount an openwrt build tree over NFS v4 >>> 2. Run make -j `cat /proc/cpuinfo | grep vendor | wc -l` ; make clean in a >>> loop >>> 3. Result after 3-4 iterations: >>> >>> State on the client >>> >>> ls -laF >>> /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm >>> >>> total 8 >>> drwxr-xr-x 2 anivanov anivanov 4096 Jul 8 11:40 ./ >>> drwxr-xr-x 3 anivanov anivanov 4096 Jul 8 11:40 ../ >>> >>> State as seen on the server (mounted via nfs from localhost): >>> >>> ls -laF >>> /var/autofs/local/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm >>> total 12 >>> drwxr-xr-x 2 anivanov anivanov 4096 Jul 8 11:40 ./ >>> drwxr-xr-x 3 anivanov anivanov 4096 Jul 8 11:40 ../ >>> -rw-r--r-- 1 anivanov anivanov 32 Jul 8 11:40 ipcbuf.h >>> >>> Actual state on the filesystem: >>> >>> ls -laF >>> /exports/work/src/openwrt/build_dir/target-mips_24kc_musl/linux-ar71xx_tiny/linux-4.14.125/arch/mips/include/generated/uapi/asm >>> total 12 >>> drwxr-xr-x 2 anivanov anivanov 4096 Jul 8 11:40 ./ >>> drwxr-xr-x 3 anivanov anivanov 4096 Jul 8 11:40 ../ >>> -rw-r--r-- 1 anivanov anivanov 32 Jul 8 11:40 ipcbuf.h >>> >>> So the client has quite clearly lost the plot. Telling it to drop caches and >>> re-reading the directory shows the file present. >>> >>> It is possible to reproduce this using a linux kernel tree too, just takes >>> much more iterations - 10+ at least. >>> >>> Both client and server run 4.19.37 from Debian buster. This is filed as >>> debian bug 931500. I originally thought it to be autofs related, but IMHO it >>> is actually something fundamentally broken in nfs caching resulting in cache >>> corruption. >> According to the reporter downstream in Debian, at >> https://bugs.debian.org/940821#26 thi seem still reproducible with >> more recent kernels than the initial reported. Is there anything Anton >> can provide to try to track down the issue? >> >> Anton, can you reproduce with current stable series? > > 100% reproducible with any kernel from 4.9 to 5.4, stable or backports. It > may exist in earlier versions, but I do not have a machine with anything > before 4.9 to test at present. Confirming you are varying client-side kernels. Should the Linux NFS client maintainers be Cc'd? > From 1-2 make clean && make cycles to one afternoon depending on the number > of machine cores. More cores/threads the faster it does it. > > I tried playing with protocol minor versions, caching options, etc - it is > still reproducible for any nfs4 settings as long as there is client side > caching of metadata. > > A. > >> >> Regards, >> Salvatore >> > > -- > Anton R. Ivanov > Cambridgegreys Limited. Registered in England. Company Number 10273661 > https://www.cambridgegreys.com/ -- Chuck Lever
Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?
> On May 17, 2018, at 5:48 PM, Moritz Schlarb <schla...@uni-mainz.de> wrote: > > Hi Chuck, > > On 17.05.2018 16:15, Chuck Lever wrote: > >> Just a shot in the dark: Wondering if v3.16 needs >> >> commit ea96d1ecbe4fcb1df487d99309d3157b4ff5fc02 >> Author: Anna Schumaker <anna.schuma...@netapp.com> >> AuthorDate: Fri Apr 3 14:35:59 2015 -0400 >> Commit: Trond Myklebust <trond.mykleb...@primarydata.com> >> CommitDate: Thu Apr 23 14:43:54 2015 -0400 >> >>nfs: Fetch MOUNTED_ON_FILEID when updating an inode > > Gosh, it seems you're right! > When I take that patch and apply it, the referrals are being followed again! > > Thanks for your idea! > Now how do we make sure it gets applied soonish? Hi Moritz- Anyone (including you or your distributor) can request that this patch be applied to the upstream v3.16 LTS branch. Since you have confirmed that it applies and fixes your problem, it would be appropriate to report that along with your backport request. -- Chuck Lever
Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?
> On May 17, 2018, at 3:53 AM, Moritz Schlarb <schla...@uni-mainz.de> wrote:
>
> Hi everyone,
>
> there might be a regression coming from this patch:
> Since it got included in 3.16.54, our clients running a recent 3.16
> kernel (like from Debian jessie-security) did not follow NFS 4.1
> referrals (issued by nfs-ganesha) anymore.
> I have built that exact Debian kernel package with just this patch
> reversed and it worked again, so I got pretty confident that this patch
> is at least strongly related to the problem.
> Pradeep also confirmed the problem happening in 3.16.54 but not in 3.16.51.
> Interestingly, this does *not* happen with 4.9 kernels, although the
> patch was part of 4.9.80...
>
> I have attached a pcap file of a machine running 3.16.56-1+deb8u1 in
> which I try to login as a user where my home directory is
> /uni-mainz.de/homes/schlarbm (with nfsrefer.zdv.uni-mainz.de:/ on
> /uni-mainz.de) which is then referred to
> fs02.uni-mainz.de:/vol/ma17/homes/schlarbm but that referral is not
> followed by the client.
>
> Please let me know if you need additional information to reproduce or
> have suggestions on what we could try.
Just a shot in the dark: Wondering if v3.16 needs
commit ea96d1ecbe4fcb1df487d99309d3157b4ff5fc02
Author: Anna Schumaker <anna.schuma...@netapp.com>
AuthorDate: Fri Apr 3 14:35:59 2015 -0400
Commit: Trond Myklebust <trond.mykleb...@primarydata.com>
CommitDate: Thu Apr 23 14:43:54 2015 -0400
nfs: Fetch MOUNTED_ON_FILEID when updating an inode
> Best regards,
> Moritz
>
> On 05.11.2017 21:45, Chuck Lever wrote:
>> Before traversing a referral and performing a mount, the mounted-on
>> directory looks strange:
>>
>> dr-xr-xr-x. 2 4294967294 4294967294 0 Dec 31 1969 dir.0
>>
>> nfs4_get_referral is wiping out any cached attributes with what was
>> returned via GETATTR(fs_locations), but the bit mask for that
>> operation does not request any file attributes.
>>
>> Retrieve owner and timestamp information so that the memcpy in
>> nfs4_get_referral fills in more attributes.
>>
>> Changes since v1:
>> - Don't request attributes that the client unconditionally replaces
>> - Request only MOUNTED_ON_FILEID or FILEID attribute, not both
>> - encode_fs_locations() doesn't use the third bitmask word
>>
>> Fixes: 6b97fd3da1ea ("NFSv4: Follow a referral")
>> Suggested-by: Pradeep Thomas <pradeeptho...@gmail.com>
>> Signed-off-by: Chuck Lever <chuck.le...@oracle.com>
>> Cc: sta...@vger.kernel.org
>> ---
>> fs/nfs/nfs4proc.c | 18 --
>> 1 file changed, 8 insertions(+), 10 deletions(-)
>>
>> I could send this as an incremental, but that just seems to piss
>> off distributors, who will just squash them all together anyway.
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
>> index 6c61e2b..2662879 100644
>> --- a/fs/nfs/nfs4proc.c
>> +++ b/fs/nfs/nfs4proc.c
>> @@ -254,15 +254,12 @@ static int nfs4_map_errors(int err)
>> };
>>
>> const u32 nfs4_fs_locations_bitmap[3] = {
>> -FATTR4_WORD0_TYPE
>> -| FATTR4_WORD0_CHANGE
>> +FATTR4_WORD0_CHANGE
>> | FATTR4_WORD0_SIZE
>> | FATTR4_WORD0_FSID
>> | FATTR4_WORD0_FILEID
>> | FATTR4_WORD0_FS_LOCATIONS,
>> -FATTR4_WORD1_MODE
>> -| FATTR4_WORD1_NUMLINKS
>> -| FATTR4_WORD1_OWNER
>> +FATTR4_WORD1_OWNER
>> | FATTR4_WORD1_OWNER_GROUP
>> | FATTR4_WORD1_RAWDEV
>> | FATTR4_WORD1_SPACE_USED
>> @@ -6763,9 +6760,7 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt
>> *client, struct inode *dir,
>> struct page *page)
>> {
>> struct nfs_server *server = NFS_SERVER(dir);
>> -u32 bitmask[3] = {
>> -[0] = FATTR4_WORD0_FSID | FATTR4_WORD0_FS_LOCATIONS,
>> -};
>> +u32 bitmask[3];
>> struct nfs4_fs_locations_arg args = {
>> .dir_fh = NFS_FH(dir),
>> .name = name,
>> @@ -6784,12 +6779,15 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt
>> *client, struct inode *dir,
>>
>> dprintk("%s: start\n", __func__);
>>
>> +bitmask[0] = nfs4_fattr_bitmap[0] | FATTR4_WORD0_FS_LOCATIONS;
>> +bitmask[1] = nfs4_fattr_bitmap[1];
>> +
>> /* Ask for the fileid of the absent filesystem if mounted_on_fileid
>> * is not supported */
>> if (NFS_SERVER(dir)->attr_bitmask[1] & FATTR4_WORD1_MOUNTED_ON_FILEID)
>> -bitmask[1] |= FATTR4_WORD1_MOUNTED_ON_FILEID;
>> +bitmask[0] &= ~FATTR4_WORD0_FILEID;
>> else
>> -bitmask[0] |= FATTR4_WORD0_FILEID;
>> +bitmask[1] &= ~FATTR4_WORD1_MOUNTED_ON_FILEID;
>>
>> nfs_fattr_init(_locations->fattr);
>> fs_locations->server = server;
>>
>
--
Chuck Lever
Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254
On Aug 8, 2010, at 12:59 AM, Ben Hutchings wrote: On Tue, 2010-07-06 at 13:05 -0400, Chuck Lever wrote: On 06/ 9/10 10:41 AM, Steven Shiau wrote: On 2010年06月06日 04:29, Ben Hutchings wrote: On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote: On 05/24/10 11:22 AM, Chuck Lever wrote: [...] We can probably remove the reverse mapping constraint for presentation addresses. A simple fix might be to change statd_canonical_name() from: freeaddrinfo(ai); if (!result) return NULL; to freeaddrinfo(ai); if (!result) return strdup(hostname); Let me know if this works. Any update? I have a patch ready for nfs-utils to fix this regression, but I need confirmation that it addresses your problem. Steven originally had this problem, not me. Steven, do you need me to build a new package with this change? Ben. Ben, Yes, please. Thanks. Any progress on this? I've heard nothing from Steven but one positive report from another user. In any case we'll include this in our package. We now have a git repository of the nfs-utils package at git://git.debian.org/kernel/nfs-utils.git; currently our changes are kept in a quilt patch series in debian/patches. Thanks, I'll submit the latest version of this to the nfs-utils maintainer. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6c244072-b1da-4f2d-8707-767dbaac1...@oracle.com
Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254
On 06/ 9/10 10:41 AM, Steven Shiau wrote: On 2010年06月06日 04:29, Ben Hutchings wrote: On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote: On 05/24/10 11:22 AM, Chuck Lever wrote: [...] We can probably remove the reverse mapping constraint for presentation addresses. A simple fix might be to change statd_canonical_name() from: freeaddrinfo(ai); if (!result) return NULL; to freeaddrinfo(ai); if (!result) return strdup(hostname); Let me know if this works. Any update? I have a patch ready for nfs-utils to fix this regression, but I need confirmation that it addresses your problem. Steven originally had this problem, not me. Steven, do you need me to build a new package with this change? Ben. Ben, Yes, please. Thanks. Any progress on this? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c33624d.2070...@oracle.com
Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254
On 05/24/10 11:22 AM, Chuck Lever wrote: On 05/21/10 09:38 PM, Ben Hutchings wrote: On Sat, 2010-05-22 at 07:49 +0800, Steven Shiau wrote: Same problem here. However, mine is on the client side. On sid system, running kernel is 2.6.32-5-686, nfs-common is 1:1.2.2-1. When I mount my NFS server 192.168.120.254, it works. However, if I want to use some tool which need to lock file to save the file on the NFS server, e.g. vgcfgbackup -f $NFS_MNT_POINT/vg.cfg I get the message lockd: cannot monitor 192.168.120.254, and the message shown on the /var/log/daemon.log: May 21 08:52:44 debian rpc.statd[1298]: STAT_FAIL to debian for SM_MON of 192.168.120.254 May 21 08:52:44 debian rpc.statd[1298]: No canonical hostname found for 192.168.120.254 [...] nfs-utils 1.2.2 includes the change: commit 8ce130c4c828b9d13d429f22160f992b9c1d45cd Author: Chuck Leverchuck.le...@oracle.com Date: Thu Jan 14 12:24:15 2010 -0500 statd: Support IPv6 in sm_mon_1_svc() This appears to have removed support for IPv4 literals. Was this intentional? statd usually requires a DNS reverse mapping for any host it monitors. Does your DNS have a reverse mapping for 192.168.120.254? It looks like the new logic is more restrictive than the old statd when mon_name is a presentation address. The old code simply allowed presentation addresses with no reverse mapping. The new code requires a reverse DNS mapping for presentation addresses. I think even an entry in /etc/hosts would allow a raw address to work in this case. We can probably remove the reverse mapping constraint for presentation addresses. A simple fix might be to change statd_canonical_name() from: freeaddrinfo(ai); if (!result) return NULL; to freeaddrinfo(ai); if (!result) return strdup(hostname); Let me know if this works. Any update? I have a patch ready for nfs-utils to fix this regression, but I need confirmation that it addresses your problem. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c0819c2.2020...@oracle.com
Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254
On 05/21/10 09:38 PM, Ben Hutchings wrote: On Sat, 2010-05-22 at 07:49 +0800, Steven Shiau wrote: Same problem here. However, mine is on the client side. On sid system, running kernel is 2.6.32-5-686, nfs-common is 1:1.2.2-1. When I mount my NFS server 192.168.120.254, it works. However, if I want to use some tool which need to lock file to save the file on the NFS server, e.g. vgcfgbackup -f $NFS_MNT_POINT/vg.cfg I get the message lockd: cannot monitor 192.168.120.254, and the message shown on the /var/log/daemon.log: May 21 08:52:44 debian rpc.statd[1298]: STAT_FAIL to debian for SM_MON of 192.168.120.254 May 21 08:52:44 debian rpc.statd[1298]: No canonical hostname found for 192.168.120.254 [...] nfs-utils 1.2.2 includes the change: commit 8ce130c4c828b9d13d429f22160f992b9c1d45cd Author: Chuck Leverchuck.le...@oracle.com Date: Thu Jan 14 12:24:15 2010 -0500 statd: Support IPv6 in sm_mon_1_svc() This appears to have removed support for IPv4 literals. Was this intentional? statd usually requires a DNS reverse mapping for any host it monitors. Does your DNS have a reverse mapping for 192.168.120.254? It looks like the new logic is more restrictive than the old statd when mon_name is a presentation address. The old code simply allowed presentation addresses with no reverse mapping. The new code requires a reverse DNS mapping for presentation addresses. I think even an entry in /etc/hosts would allow a raw address to work in this case. We can probably remove the reverse mapping constraint for presentation addresses. A simple fix might be to change statd_canonical_name() from: freeaddrinfo(ai); if (!result) return NULL; to freeaddrinfo(ai); if (!result) return strdup(hostname); Let me know if this works. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfa99cd.2040...@oracle.com
