On Wed, Nov 5, 2014 at 12:27 AM, Christoph Hellwig wrote:
> On Mon, Nov 03, 2014 at 11:04:27AM -0800, Linus Torvalds wrote:
>> Oh, so you don't actually need any file contents at all?
>>
>> If that is actually a real usage, then maybe we should just say that
>> "O_TMPFILE|O_RDONLY" is fine, and re
On Mon, Nov 3, 2014 at 9:06 AM, Andy Lutomirski wrote:
>> That doesn't help because we explicitly reject O_RDONLY when combined
>> with O_TMPFILE.
>
> I think I'm missing something. How is an O_RDONLY temporary file
> useful? Wouldn't you want an O_RDWR tempfile with mode 0400 or
> something lik
On Thu, Oct 30, 2014 at 6:04 PM, Linus Torvalds
wrote:
> On Thu, Oct 30, 2014 at 5:57 PM, Eric Rannaud wrote:
>> Yes, there definitely is a glibc bug: a fix is being worked on and it
>> looks like it will go in. The change replaces the test for O_CREAT by
>> a test
in a code path that didn't have
it at compile time (where flags was a build constant). Other wrappers
add O_LARGEFILE. One wrapper for openat checks that dirfd is a
directory (no idea why, as the kernel does the same check -- without a
race; maybe to try to guarantee ENOTDIR on some old kernel version?
e the kernel looks for the 4th argument
of a syscall in R10. Indeed, the syscall calling convention differs from
the regular calling convention in this respect on x86_64. So the kernel
sees mode = 0 when trying to use glibc openat() with O_TMPFILE, and
fails with EACCES.
Signed-off-by: Eric Rannaud
---
Hi,
Between 3.13.5 and 3.15.4, suspend became partially broken on Macbook Pro 15
(late 2013): a few minutes after wakeup from the *second* suspend following a
fresh boot, the screen will randomly turn itself off at shorter and shorter
time intervals, and turn itself back on after a few seconds and
Hi,
Between 3.15.4 and 3.15.8, there was an increase in idle power consumption on
Apple Macbook Pro 15 (late 2013) on a freshly booted system (no wifi driver
loaded; brightness set to 4/100; X running; no desktop environment, except
Awesome), from 6.5W to about 10.5W, as reported by powertop.
In
On Tue, Mar 27, 2007 at 07:17:49PM +0200, Cornelia Huck wrote:
> On Tue, 27 Mar 2007 11:25:57 +0200,
> "Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > Checking the uevent return value, will not prevent any malfunction,
> > usually this kind of "error handling" just prevents bringing up a
> > whole sub
On Mon, Mar 26, 2007 at 01:22:32AM -0800, Andrew Morton wrote:
> On Mon, 26 Mar 2007 11:09:49 +0200 Cornelia Huck <[EMAIL PROTECTED]> wrote:
> > > If so, do you think I should labour on with
> > > uevent-improve-error-checking-and-handling.patch plus your fix, or should
> > > I
> > > drop the lot?
Subject: uevent: use add_uevent_var() instead of open coding it
From: Eric Rannaud <[EMAIL PROTECTED]>
Make use of add_uevent_var() instead of (often incorrectly)
open coding it.
Signed-off-by: Eric Rannaud <[EMAIL PROTECTED]>
---
drivers/amba/bus.c
Subject: uevent: improve error checking and handling
From: Eric Rannaud <[EMAIL PROTECTED]>
add_uevent_var() is used w/o checking for its return value, even though
it is possible for those calls to return -ENOMEM.
Signed-off-by: Eric Rannaud <[EMAIL PROTECTED]>
---
On Thu, 2005-04-14 at 01:30 -0700, Andy Isaacson wrote:
> In particular, your defense here is specious. I agree that second
> preimage is an unmanagably large problem for SHA1 for the forseeable
> future (say, 8 years out), but collision results almost always result in
> partially-controlled attac
On Wed, 2005-04-13 at 09:02 -0400, Lennart Sorensen wrote:
> modprobe nvidia || m-a -t prepare nvidia && m-a -t build nvidia && m-a -t
> install nvidia && modprobe nvidia
Something along the lines of:
modprobe nvidia || sh NVIDIA-Linux-x86-1.0-6629-pkg1.run -s -f --no-network &&
modprobe nvidia
Simply put, the best known attack of SHA-1 takes 2^69 hash operations.
( http://www.schneier.com/blog/archives/2005/02/sha1_broken.html )
The attack is still only an unpublished paper and has not yet been
implemented. An attack is: you try as hard as you can to find a collision
between two arbitra
14 matches
Mail list logo
