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
On Wed, Nov 5, 2014 at 12:27 AM, Christoph Hellwig h...@infradead.org 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
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
On Mon, Nov 3, 2014 at 9:06 AM, Andy Lutomirski l...@amacapital.net 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
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 te
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?
It's been here since 2005, wh
onvention 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
---
fs/namei.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/namei
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 e...@nanocritical.com
---
fs/namei.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/namei.c b/fs/namei.c
index
).
--
Eric Rannaud e...@nanocritical.com
Nanocritical, CEO
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Oct 30, 2014 at 6:04 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Oct 30, 2014 at 5:57 PM, Eric Rannaud e...@nanocritical.com 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
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
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
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
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
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
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 subsystem, or
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
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? (I'm
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]>
---
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]
---
drivers/base
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 | 13 +++---
drivers
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
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 attack
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
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
should
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
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
28 matches
Mail list logo
