search for: eoverflow

On Mon, Apr 22, 2019 at 07:50:22PM -0500, Eric Blake wrote: > Previously, we were squashing EOVERFLOW into EINVAL; continue to do so > at points in the protocol where the client may not be expecting > EOVERFLOW. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > server/protocol.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > >...

[adding NBD list] On 4/23/19 2:36 AM, Richard W.M. Jones wrote: > On Mon, Apr 22, 2019 at 07:50:22PM -0500, Eric Blake wrote: >> Previously, we were squashing EOVERFLOW into EINVAL; continue to do so >> at points in the protocol where the client may not be expecting >> EOVERFLOW. > > The protocol spec is unclear on whether EOVERFLOW can be returned in > cases other than the DF flag being set. Whether we include this patch > or not seems...

On Tue, Apr 23, 2019 at 07:38:41AM -0500, Eric Blake wrote: > [adding NBD list] > > On 4/23/19 2:36 AM, Richard W.M. Jones wrote: > > On Mon, Apr 22, 2019 at 07:50:22PM -0500, Eric Blake wrote: > >> Previously, we were squashing EOVERFLOW into EINVAL; continue to do so > >> at points in the protocol where the client may not be expecting > >> EOVERFLOW. > > > > > The protocol spec is unclear on whether EOVERFLOW can be returned in > > cases other than the DF flag being set. Whether we include...

Previously, we were squashing EOVERFLOW into EINVAL; continue to do so at points in the protocol where the client may not be expecting EOVERFLOW. Signed-off-by: Eric Blake <eblake@redhat.com> --- server/protocol.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/server/protocol.c b/server/prot...

An issue was found with the netBeans installer where the installation was failing on a large ZFS filesystem. This resulted in CR 6560644 (zfs statvfs f_frsize needs work). The issue is that large filesystems can cause EOVERFLOW on statvfs() calls. This behavior is documented in the statvfs(2) man page, but I think we can do better. The problem was initially reported against ZFS, and my first fix was to zfs_statvfs(). But the VFS_STATVFS routines only see a statvfs64, so they have no way to tell if they''re about...

Mapping of EOVERFLOW was missed in commit 6f8c8084. Mapping of EOPNOTSUPP is essential for .zero to trigger a fallback to .pwrite, missed in commit 6c0e00e9 (not to mention that it becomes a valid protocol failure once fast zero support is added). There is no Unix.ENOTSUP, or that would get the same treatment per com...

...o trigger a non-EIO failure, a script had to output _exactly_ 'EINVAL ' or similar, with one trailing space and no message, because we forgot to limit the length of the string comparison. Fix things to tolerate an error name without a message, as well as to be case-insensitive. Also, parse EOVERFLOW (missed in commit 6f8c8084). Signed-off-by: Eric Blake <eblake@redhat.com> --- I'm also working on adding tests/test-sh-errors.h to ensure we don't regress, I'll push that along with this once I get it working. plugins/sh/nbdkit-sh-plugin.pod | 4 +-- plugins/sh/call.c...

...expose portions of the heap; my patch 7 loses some time on extra memset()s to avoid that, although it's probably in the noise compared to the time spent talking over sockets to the remote server. Eric Blake (7): protocol: Send correct structured reply error for non-Linux protocol: Support EOVERFLOW RFC: protocol: Only send EOVERFLOW when valid nbd: Honor server global flags on little-endian protocol: Add helpers for error response handling nbd: Implement NBD_OPT_GO client request nbd: Implement structured replies common/protocol/protocol.h | 21 +- plugins/nbd/nbd.c | 43...

...useless index_cnt--? :) 2) Regardless of that, we have to deal with existing entry items with giant keys. If for no other reason than big jerks making corrupt images and leaving them on usb keys in Josef''s driveway. Should we drop the silly INT_MAX setting for 64bit callers and return -EOVERFLOW for 32bit callers? (That''d be gross, but not unheard of. ext4 has grown htree behaviour that depends on compat detection: see its is_32bit_api() callers.) I can make up some fixes but I''d love to hear strong opinions first, if anyone''s got ''em :). - z -- To u...

I see very odd results from rsync 2.4.7pre1, the latest cvs version (sept 12, i think was the last modified file). We have a number of network-attached storage devices. 10/100 ethernet, nfs2 mounted (under nfs3, they buffer deletes, and recursive deletions fail). Usually, these are kept syncronized across a wan by a nightly cronjob, We have a few we keep in reserve, which we syncronize

...ain: > > 1.199490 libusb_get_report: Unknown error > 1.199512 Can't retrieve Report 0c: Input/output error > > Seems you are talking about Dmitry's case (overflow). > > > you're right: your issues are the same, but BSD doesn't report EOVERFLOW > has it should. > while Dmitry is running on Linux, the patch should work there. > > @Robert: could you please run the test again (with wathever version), > using debug level 5 (-DDDDD) and doing "export USB_DEBUG=3" before > launching the driver? > > if there is...

filldir_t can take this, so don't turn de->inode into a 32 bit value. Right now this doesn't make a difference since no ocfs2 inodes overflow that, but it could be a nasty surprise later on if some kernel code is calling ocfs2_dir_foreach_blk() and expecting real inode numbers back... Signed-off-by: Mark Fasheh <mark.fasheh@oracle.com> --- fs/ocfs2/dir.c | 2 +- 1 files

...ioread16(&cfg->topo_config.count); + if (!offset || !count) + return 0; + + viommu = kzalloc(sizeof(*viommu), GFP_KERNEL); + if (!viommu) + return -ENOMEM; + + viommu->dev = dev; + + for (i = 0; i < count; i++, offset += len) { + if (offset + sizeof(*cur) > max_len) { + ret = -EOVERFLOW; + goto err_free; + } + + cur = (void __iomem *)cfg + offset; + len = ioread16(&cur->length); + if (offset + len > max_len) { + ret = -EOVERFLOW; + goto err_free; + } + + ep = viommu_parse_node((void __iomem *)cur, len); + if (!ep) { + continue; + } else if (IS_ERR(ep)) {...

...t || !count) > + return 0; > + > + viommu = kzalloc(sizeof(*viommu), GFP_KERNEL); > + if (!viommu) > + return -ENOMEM; > + > + viommu->dev = dev; > + > + for (i = 0; i < count; i++, offset += len) { > + if (offset + sizeof(*cur) > max_len) { > + ret = -EOVERFLOW; > + goto err_free; > + } > + > + cur = (void __iomem *)cfg + offset; > + len = ioread16(&cur->length); > + if (offset + len > max_len) { > + ret = -EOVERFLOW; > + goto err_free; > + } > + > + ep = viommu_parse_node((void __iomem *)cur, len); &...

...ith statvfs() and statvfs64() returning different values for f_frsize, f_blocks, f_bfree, and f_bavail as long as the values f_frsize*f_blocks, f_frsize*f_bfree, and f_frsize*f_bavail are the same (using types for the multiplication that don''t overflow) in both calls. If statvfs() returns EOVERFLOW if the values returned would be different from those returned by statvfs64(), I''ll be happy (at least as long as we don''t have statvfs64() lie to make this true ;-} ). > >But I don''t see why we couldn''t round up the used space / round (down) the >free...

This is the next patch series for scrub userland tools. Change log v1->v2: - commands now reachable as "btrfs scrub ..." instead of "btrfs filesystem scrub ..." - ability to scrub a single device instead of a whole file system - superfluous command line options removed - resume is now a separate command ("scrub resume") instead of "scrub start -r" -

...scii_strncasecmp (ebuf, "EINVAL", 6) == 0) { err = EINVAL; skip = 6; } - else if (strncasecmp (ebuf, "ENOSPC", 6) == 0) { + else if (ascii_strncasecmp (ebuf, "ENOSPC", 6) == 0) { err = ENOSPC; skip = 6; } - else if (strncasecmp (ebuf, "EOVERFLOW", 9) == 0) { + else if (ascii_strncasecmp (ebuf, "EOVERFLOW", 9) == 0) { err = EOVERFLOW; skip = 9; } - else if (strncasecmp (ebuf, "ESHUTDOWN", 9) == 0) { + else if (ascii_strncasecmp (ebuf, "ESHUTDOWN", 9) == 0) { err = ESHUTDOWN; skip...

...re when >> present, and the server to advertise support for it. >> >> Signed-off-by: Eric Blake <eblake@redhat.com> >> +++ b/nbd/server.c >> @@ -55,6 +55,8 @@ static int system_errno_to_nbd_errno(int err) >> return NBD_ENOSPC; >> case EOVERFLOW: >> return NBD_EOVERFLOW; >> + case ENOTSUP: >> + return NBD_ENOTSUP; > > This may provoke returning NBD_ENOTSUP in other cases, not only new one we are going to add. Correct. But the spec only said SHOULD avoid ENOTSUP in those other cases, not MUST av...

...trying to send incremental backups (b89 -> b101). Do you know about any bugs related to that? I did a look on the archives, and google but could not find anything. What i did find was something related with wrong timestamps (32bits), and some ZFS test on the code: zfs_vnops.c. But the error is EOVERFLOW... Thanks a lot for your time! -- This message posted from opensolaris.org

...| > Hello when i get this message what is wrong: | > | > /PTS.0.db2inst1.NODE0000.CATN0000.20030123062324.001: Value too | > large to be stored in data type | > | > Regards Boris [...] +-----X8 I have also seen that message with times before 1970. This is the standard text for EOVERFLOW. /Michael -- This space intentionally left non-blank. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html