search for: underflows

Hi Nouveau developers, We've posted a short document about disabling display underflow reporting on GK104, which is needed due to an incorrect setting in some production GK104 VBIOSes: ftp://download.nvidia.com/open-gpu-doc/gk104-disable-underflow-reporting/1/gk104-disable-underflow-reporting.txt Thanks, - Andy

Multiple input validation failures in X server extensions ========================================================= All theses issuses can lead to local privileges elevation on systems where the X server is running privileged. * CVE-2020-14345 / ZDI CAN 11428 XkbSetNames Out-Of-Bounds Access The handler for the XkbSetNames request does not validate the request length before accessing its

fisher.test() gives a very small p-value, which is underflow on my machine. However, the log of it should not be underflow. I'm wondering if there is a way get log() of a small p-value. An approximation is acceptable in this case. Thank you! > fisher.test(rbind(c(10000,100000),c(100000,10000000)))$p.value [1] 0

Dear all, I'm a bit concerned about underflow problems. Such problems typically occur when two almost equal numbers are subtracted. I was wondering if R has any mechanisms for warning users about potential problems, or if any policy has been developed? To check, I just did: > 1.0000000000000001 - 1 [1] 0 > 1.000000000000001 - 1 [1] 1.110223e-15 > 1.00000000000001 - 1 [1]

The besselK() function knows about overflows/underflows internally; there is a constant xmax_BESS_K in src/nmath/bessel.h (and referred to only in bessel_k.c), equal to 705.342, which is checked if expon.scaled is FALSE. (The equivalent number for bessel_i.c is 709, defined as exparg_BESS in bessel.h.) However, besselK(x) silently returns +Inf if x>...

When xl is called to create a domU and there is not enough memory available, then the autoballooning is called to extract memory from dom0. During the ballooning a loop in libxl_wait_for_free_memory() waits unless enough memory is available to create the domU. But because of a variable-underflow the loop can finish too soon and xl finally aborts with the message: xc: error: panic:

Hello http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1536 "Integer underflow in the file_printf function in the "file" program before 4.20 allows user-assisted attackers to execute arbitrary code via a file that triggers a heap-based buffer overflow." Is FreeBSD 5.x/6.x affected too? It looks the System has file 4.12. The port has 4.20. Regards, Thomas -- Terry

...st majority of such app developers would happily trade precision for performance, even as the default behavior. However, the place where trouble DOES occur is with overflow and underflow behavior at critical points. Changing the order of operations, or combining operations, can cause overflows or underflows to occur that wouldn't otherwise occur, and vice versa. Sometimes this is beneficial, but it is almost always unexpected. Underflows may sound less important in this regard, but they can be worse than overflows, because they can mostly or completely eliminate the significant bits, in complete...

The "vma->vm_pgoff" variable is an unsigned long so if it's larger than INT_MAX then "index" can be negative leading to an underflow. Fix this by changing the type of "index" to "unsigned long". Fixes: ddd89d0a059d ("vhost_vdpa: support doorbell mapping via mmap") Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> ---

I'm still trying to install R on my Irix machine. Now I have a new problem that crops up during the checks. I've found the root cause, and it's that R is returning zero for certain things for reasons I don't understand. 2.225073859e-308, entered directly into R, responds "2.225074e-308". 2.225073858e-308 responds "0". Their negative values respond

I'm still trying to install R on my Irix machine. Now I have a new problem that crops up during the checks. I've found the root cause, and it's that R is returning zero for certain things for reasons I don't understand. 2.225073859e-308, entered directly into R, responds "2.225074e-308". 2.225073858e-308 responds "0". Their negative values respond

...would happily trade precision for > performance, even as the default behavior. However, the place where trouble > DOES occur is with overflow and underflow behavior at critical points. > Changing the order of operations, or combining operations, can cause > overflows or underflows to occur that wouldn’t otherwise occur, and vice > versa. for the moment I'm distinguishing (mentally) between transformations that introduce a uniformly bounded relative error, for example x+0 -> x, or x/constant -> x * (1/constant) if constant and 1/constant are normal (and not...

https://bugzilla.mindrot.org/show_bug.cgi?id=3732 Bug ID: 3732 Summary: An integer underflow may occur due to arithmetic operation (unsigned subtraction) between values '0' and '67108864', where the first value comes from the expression 'h4 + b' and the second value comes from

I have a question about PLC used by OPUS. We are using OPUS for streaming music in some application. Due to some network problems, we are running into problems related to clock drifts. This causes jitter buffer underflows at the receiver and hence we need to rebuffer the jitter buffer periodically. We are looking at the root cause of this problem (drift), but that's besides the point. During jitter buffer rebuffering, we are sending null frames to the OPUS decode, indicating lost frames. My question is - Is thi...

Hi -- I'm trying to package R for inclusion on some upcoming Red Hat Powertools distribution. I have started with the 0.61 version packaged by Martyn Plummer <plummer at iarc.fr> (Thanks Martyn!) and have upgraded to 0.62-2. I have succeeded in running R demo's on i386-redhat-linux-gnu, and now I am also trying to get the alpha and sparc versions working. On sparc-redhat-linux,

we can't use nouveau_bo_ref here as no ttm object was allocated and nouveau_bo_ref mainly deals with that. Simply deallocate the object. Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nouveau_gem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drm/nouveau/nouveau_gem.c b/drm/nouveau/nouveau_gem.c index e11303fbc..45582a8dc 100644 ---

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 925681454d7b557d404b5d28ef4469fac1b2e105 ] we can't use nouveau_bo_ref here as no ttm object was allocated and nouveau_bo_ref mainly deals with that. Simply deallocate the object. Signed-off-by: Karol Herbst <kherbst at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 925681454d7b557d404b5d28ef4469fac1b2e105 ] we can't use nouveau_bo_ref here as no ttm object was allocated and nouveau_bo_ref mainly deals with that. Simply deallocate the object. Signed-off-by: Karol Herbst <kherbst at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin

From: Karol Herbst <kherbst at redhat.com> [ Upstream commit 925681454d7b557d404b5d28ef4469fac1b2e105 ] we can't use nouveau_bo_ref here as no ttm object was allocated and nouveau_bo_ref mainly deals with that. Simply deallocate the object. Signed-off-by: Karol Herbst <kherbst at redhat.com> Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin

Hi guys, a user at Gentoo Bugzilla, reported that he archives files with a artificial timestamp of 1970-01-01 on an ext3 partition on his amd64 box. After remounting that partition, the file date becomes 2106-02-07. I confirmed this bug and also tested it on several other partitions (xfs, reiserfs) and they don't have this problem, just ext2 and ext3 have it. This problem also