On Sun, Feb 24, 2008 at 04:32:40PM +, John Levon wrote:
> > There are plenty of things that can be done, including using search
> > paths to try to find vmlinuz; or maybe even proposing a new standard
> > such as say for example /lib/modules/`uname -r`/vmlinux being a
>
> At the time when I wa
On Sat, Feb 23, 2008 at 01:53:35PM +, John Levon wrote:
> On Sat, Feb 23, 2008 at 12:37:24PM +0100, Ingo Molnar wrote:
>
> > It's 200 lines of pretty well isolated code for something that is
> > already much more usable to me than 10 years of oprofile. Really, i'd
> > much rather take 200 li
On Wed, Feb 20, 2008 at 07:13:16PM +0200, Adrian Bunk wrote:
> > A third option would be if people add new functions (with no users) in
> > -rc2 or -rc3 timeframes as long as it is part of a fully reviewed
> > patch with users that will use those new features in various kernel
> > development trees
On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote:
> Two things may largely eliminate the need for parallel branches.
>
> 1. Do infrastructure changes and whole tree wide refactoring etc. in a
> compatible manner with a brief but nonzero transition period.
>
> 2. Insert a second merg
On Mon, Feb 18, 2008 at 05:16:55PM +0100, Tomasz Chmielewski wrote:
> Theodore Tso schrieb:
>
>> I'd really need to know exactly what kind of operations you were
>> trying to do that were causing problems before I could say for sure.
>> Yes, you said you were removing
On Mon, Feb 18, 2008 at 04:57:25PM +0100, Andi Kleen wrote:
> > Use cp
> > or a tar pipeline to move the files.
>
> Are you sure cp handles hardlinks correctly? I know tar does,
> but I have my doubts about cp.
I *think* GNU cp does the right thing with --preserve=links. I'm not
100% sure, thoug
On Mon, Feb 18, 2008 at 04:02:36PM +0100, Tomasz Chmielewski wrote:
> I tried to copy that filesystem once (when it was much smaller) with "rsync
> -a -H", but after 3 days, rsync was still building an index and didn't copy
> any file.
If you're going to copy the whole filesystem don't use rsync
On Mon, Feb 18, 2008 at 02:31:40PM +0100, Ingo Molnar wrote:
> i guess this explains what static code metrics already suggest:
Am I right in assuming that code-quality is just a program which runs
checkpatch.pl and measures the number of warnings and calls them
errors?
On Mon, Feb 18, 2008 at 04:18:23PM +0100, Andi Kleen wrote:
> On Mon, Feb 18, 2008 at 09:16:41AM -0500, Theodore Tso wrote:
> > ext3 tries to keep inodes in the same block group as their containing
> > directory. If you have lots of hard links, obviously it can't really
>
On Mon, Feb 18, 2008 at 03:03:44PM +0100, Andi Kleen wrote:
> Tomasz Chmielewski <[EMAIL PROTECTED]> writes:
> >
> > Is it normal to expect the write speed go down to only few dozens of
> > kilobytes/s? Is it because of that many seeks? Can it be somehow
> > optimized?
>
> I have similar problems
> So please deal with it like most other subsystem maintainers do and stop
> complaining about "code churn" - nobody but you changes the ext3
> codebase, it's one of the codebases least affected by general kernel
> flux, it's an ultimate "leaf" subsystem.
Right, sorry. I misread the filename;
On Mon, Feb 18, 2008 at 03:12:09PM +0200, Adrian Bunk wrote:
> If me resending this old patch collides with something finally getting a
> user this part of my patch shouldn't be applied now (but you might get
> it again in 6 months if it's still unused...).
>
> But generally such conflicts would
On Mon, Feb 18, 2008 at 08:12:29AM +0100, Ingo Molnar wrote:
> > Nack. I don't object to un-exporting journal_update_superblock(),
> > because that is pretty internal, but the other functions are intended
> > specifically for use by code outside of JBD. For example, the journal
> > checksum pa
On Sun, Feb 17, 2008 at 06:55:06PM +0100, Julia Lawall wrote:
> From: Julia Lawall <[EMAIL PROTECTED]>
>
> if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
> side-effects to allow a definition of BUG_ON that drops the code completely.
Hi, in the future, please separate ext
On Fri, Feb 15, 2008 at 04:49:39PM -0800, Dave Hansen wrote:
> On Fri, 2008-02-15 at 19:32 -0500, Theodore Tso wrote:
> > On Fri, Feb 15, 2008 at 02:37:30PM -0800, Dave Hansen wrote:
> > >
> > > This patch adds two function mnt_want_write() and mnt_drop_write().
>
On Fri, Feb 15, 2008 at 02:37:30PM -0800, Dave Hansen wrote:
>
> This patch adds two function mnt_want_write() and mnt_drop_write().
> These are used like a lock pair around and fs operations that might
> cause a write to the filesystem.
Argh, is there some reason why this couldn't have gotten me
On Tue, Feb 12, 2008 at 10:16:53PM -0800, Greg KH wrote:
> I was amazed at how slow stgit was when I tried it out. I use
> git-quiltimport a lot and I don't think it's any slower than just using
> quilt on its own. So I think that the speed issue should be the same.
I like using "guilt" because
On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote:
> On Tue, 12 Feb 2008, Greg KH wrote:
> >
> > Perhaps you need to switch to using quilt. This is the main reason why
> > I use it.
>
> Btw, on that note: if some quilt user can send an "annotated history file"
> of their quilt usag
On Tue, Feb 12, 2008 at 03:28:26PM -0800, David Miller wrote:
> From: Jan Engelhardt <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 15:00:20 +0100 (CET)
>
> > Something looks wrong here. Why would btrfs need to zero at all?
>
> So that existing superblocks on the partition won't
> be interpreted as
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote:
> On Tue, Feb 12, 2008 at 11:55:45AM -0800, Linus Torvalds wrote:
> > >
> > > Not it isn't. To quote you a number of years ago:
> > > "Linux is evolution, not intelligent design"
I think this statement has been used unfortunately as a ha
On Mon, Feb 11, 2008 at 11:06:17PM -0800, Arjan van de Ven wrote:
> There is maybe a middle ground in this -next idea; as very first
> part of the series, the new api gets added, current users converted
> and api marked __deprecated.
>
> Then there's a second part to the patch, which is a separate
On Mon, Feb 11, 2008 at 11:45:55PM -0500, Trond Myklebust wrote:
> It would be very nice to have a separate tree with _only_ API changes
> that could be frozen well before Linus' merge window opens. It should be
> a requirement that maintainers use this tree as a basis for testing API
> changes and
On Wed, Feb 06, 2008 at 03:38:52AM -0800, David Schwartz wrote:
> >
> > Ndiswrapper loads and executes code with not GPLv2 compatible licences
> > in a way in the kernel that might be considered similar to a GPLv2'ed
> > userspace program dlopen() a dynamic library file with a not GPLv2
> > com
On Wed, Feb 06, 2008 at 09:11:27AM +0100, Jiri Kosina wrote:
> On Tue, 5 Feb 2008, Theodore Tso wrote:
>
> I have also seen sound working flawlessly on another X61s. Maybe they
> changed some chipset revisions on the fly, or whatever.
>
> What does lspci -v show for you
On Tue, Feb 05, 2008 at 10:16:08PM +0100, Jiri Kosina wrote:
> [ added Takashi ]
>
> On Tue, 5 Feb 2008, Felipe Balbi wrote:
>
> > > > > > Could anyone make T61P's ICH8 sound controller to work properly?
> > Good that there's a lot of people using T61p, it's a good machine.
> > I'll upgrade my BI
On Sat, Feb 02, 2008 at 10:55:24AM -0500, Theodore Ts'o wrote:
> In the mm tree is a patch queued up to nuke iget(). So replace use of
> iget() with iget_locked(). I will be pushing this to Linus shortly.
Oops, wrong version of the patch; this is the correct one.
On Tue, Jan 29, 2008 at 10:54:03PM +0100, Jan Engelhardt wrote:
>
> On Jan 29 2008 07:53, Theodore Tso wrote:
> >
> >>fwiw, diffstat is confused by git's diff output; you need to use
> >>'diffstat -p1'
>
> I am seeing normal behavior:
>
>fwiw, diffstat is confused by git's diff output; you need to use
>'diffstat -p1'
Argh, I have *got* to create a script that does this automatically.
Revised diffstat -p1 output follows...
- Ted
Documentation/filesystems/ext4.txt | 20
On Mon, Jan 28, 2008 at 07:30:05PM +, Pavel Machek wrote:
>
> As user pages are always in highmem, this should be easy to decide:
> only send SIGDANGER when highmem is full. (Yes, there are
> inodes/dentries/file descriptors in lowmem, but I doubt apps will
> respond to SIGDANGER by closing fi
On Wed, Jan 23, 2008 at 02:06:54PM -0800, Andrew Morton wrote:
> brelse() should only be used when the bh might be NULL - put_bh()
> can be used here.
>
> Please review all ext4/jbd2 code for this trivial speedup.
I've reviewed all of the pending patches in the stable queue for this
speedup, and
On Fri, Jan 25, 2008 at 05:55:51PM -0800, Bryan Henderson wrote:
> I was surprised to see AIX do late allocation by default, because IBM's
> traditional style is bulletproof systems. A system where a process can be
> killed at unpredictable times because of resource demands of unrelated
> proce
On Thu, Jan 24, 2008 at 11:25:32AM +0530, Aneesh Kumar K.V wrote:
> +static int free_ext_idx(handle_t *handle, struct inode *inode,
> + struct ext4_extent_idx *ix)
> +{
> + int i, retval = 0;
> + ext4_fsblk_t block;
> + struct buffer_head *bh;
> +
On Fri, Jan 25, 2008 at 10:34:25AM -0600, Eric Sandeen wrote:
> > But it was this concern which is why ext3 never exported freeze
> > functionality to userspace, even though other commercial filesystems
> > do support this. It wasn't that it wasn't considered, but the concern
> > about whether or
On Fri, Jan 25, 2008 at 03:18:51PM +0300, Dmitri Monakhov wrote:
> First of all Linux already have at least one open-source(dm-snap),
> and several commercial snapshot solutions.
Yes, but it requires that the filesystem be stored under LVM. Unlike
what EVMS v1 allowed us to do, we can't currentl
On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:
> In practice, there is a small number of programs that are both the
> common memory hogs and should be able to reduce their memory consumption
> by 10% or 20% without big problems when requested (e.g. Java VMs,
> Firefox and databases co
On Tue, Jan 22, 2008 at 12:00:50AM -0700, Andreas Dilger wrote:
> > AIX had SIGDANGER some 15 years ago. Admittedly, that was sent when
> > the system was about to hit OOM, not when it was about to start swapping.
>
> I'd tried to advocate SIGDANGER some years ago as well, but none of
> the kerne
On Sat, Jan 19, 2008 at 08:10:20PM -0800, Daniel Phillips wrote:
>
> I can see value in preemptively loading indirect blocks into the buffer
> cache, but is building a second-order extent tree really worth the
> effort? Probing the buffer cache is very fast.
It's not that much effort, and for
On Thu, Jan 17, 2008 at 04:31:48PM -0800, Bryan Henderson wrote:
> But I heard some years ago from a disk drive engineer that that is a myth
> just like the rotational energy thing. I added that to the discussion,
> but admitted that I haven't actually seen a disk drive write a partial
> sector
On Wed, Jan 16, 2008 at 09:02:50PM -0500, Daniel Phillips wrote:
>
> Have you observed that in the wild? A former engineer of a disk drive
> company suggests to me that the capacitors on the board provide enough
> power to complete the last sector, even to park the head.
>
The problem isn't wit
On Tue, Jan 15, 2008 at 01:15:33PM +, Christoph Hellwig wrote:
> They won't fsck in planned downtimes. They will have to use fsck when
> the shit hits the fan and they need to. Not sure about ext3, but big
> XFS user with a close tie to the US goverment were concerned about this
> case for r
On Mon, Jan 14, 2008 at 12:23:10AM +0200, Tuomo Valkonen wrote:
> On 2008-01-14 00:13 +0200, Tuomo Valkonen wrote:
> > Also, I must say that e2fsck is brain-damaged, if it can be confused
> > by/do the stupid then when the system clock has warped by just a few
> > hours, not the _days_ that a file
On Thu, Jan 10, 2008 at 03:41:11PM +0200, Tuomo Valkonen wrote:
> On 2008-01-10 08:16 -0500, Theodore Tso wrote:
> > > It displays just the right time. On boot anyway. (Linux has had some
> > > serious problems keeping the time after the switch from 2.6.7 to 2.6.14,
> >
On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
>
> Ok, but let's look at this a bit more opportunistic / optimistic.
>
> Even after a black-out shutdown, the corruption is pretty minimal, using
> ext3fs at least.
>
After a unclean shutdown, assuming you have decent hardware that
does
On Fri, Jan 11, 2008 at 11:41:40AM -0800, Linus Torvalds wrote:
>
> (I also wonder if we should limit the number of entries we print out.
> Sometimes the stack frame ends up being so deep that we lose the
> *important* stuff. I think it might be good idea to have some rule like
> "the first 5 e
On Wed, Jan 09, 2008 at 02:16:52PM +, Tuomo Valkonen wrote:
> On 2008-01-09, Mathieu SEGAUD <[EMAIL PROTECTED]> wrote:
> > fix your hardware clock then
>
> It displays just the right time. On boot anyway. (Linux has had some
> serious problems keeping the time after the switch from 2.6.7 to 2.
On Wed, Jan 09, 2008 at 02:55:53AM -0500, [EMAIL PROTECTED] wrote:
>
> Does this create a snapshot of the *disk* at that moment, or does it
> capture "disk plus still-to-be-written blocks in the cache"?
> (Phrased differently, does it Do The Right Thing regarding "blocks
> queued before lvcreate"
On Wed, Jan 09, 2008 at 11:28:21AM +0100, Matthias Schniedermeyer wrote:
> On 09.01.2008 11:21, Matthias Schniedermeyer wrote:
> > On 09.01.2008 09:56, Tuomo Valkonen wrote:
> > > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
> > > > That what LABEL und UUID-Support in mount is for.
> >
On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> On Jan 8, 2008 7:15 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> > That will fix the this issue. The problem you are facing is that you
> > have your hardware clock set to ticking localtime, instead of G
On Tue, Jan 08, 2008 at 09:51:53PM +0100, Andi Kleen wrote:
> Theodore Tso <[EMAIL PROTECTED]> writes:
> >
> > Now, there are good reasons for doing periodic checks every N mounts
> > and after M months. And it has to do with PC class hardware. (Ted's
> >
On Tue, Jan 08, 2008 at 12:19:44PM -0800, Daniel Walker wrote:
> > But is discourage the creation of pure clean-up patches because it
> > may have a disturbing effect on several other peoples work.
>
> pure clean ups are _good_ patches , are they not?
>
Not necessarily. Whether or not it is req
On Tue, Jan 08, 2008 at 10:01:19AM -0800, Daniel Walker wrote:
> > It is a simple pain/benefit issue.
> > Fixing the 25 errors and 13 warnings in kernel/profile.c may look
> > like an easy task but then we put additional burden on the 10 people
> > that have patches pending for this file.
>
> This
On Tue, Jan 08, 2008 at 05:01:30PM +, Tuomo Valkonen wrote:
> On 2008-01-08, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > tune2fs -i0 -c0 device for each file system
> >
> > Yes that should be default, unfortunately it is not. It's one
> > of the first things I do on new machines.
>
> I hav
On Sat, Jan 05, 2008 at 01:12:44AM +0100, Paolo Ciarrocchi wrote:
> Isn't it a timing problem?
> I mean, I guess that codying style fixes are OK if there is a good
> coordination
> with the maintainer and patches are sent with the right timing in
> order to not cause
> problems in the process.
Bu
On Fri, Jan 04, 2008 at 05:30:00PM +0100, Andi Kleen wrote:
>
> Exactly. And looking at the patch the old code was already perfectly
> readable anyways. Benefit about zero.
File this under the "checkpatch.pl" considered harmful category
The problem is not with the tool, but that at least *som
On Fri, Jan 04, 2008 at 02:49:07PM +0100, Mathieu SEGAUD wrote:
> Vous m'avez dit récemment :
>
> > Coding-style only changes tends to screw up our ability to merge
> > pending patches, but I'll take care of it, thanks
>
> yep, I noticed that...
> would you rather me wait till 2.6.24 is out ?
I'
Coding-style only changes tends to screw up our ability to merge
pending patches, but I'll take care of it, thanks.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
On Tue, Dec 25, 2007 at 04:34:18AM +0100, Andi Kleen wrote:
> > And is /sys/slab
> > guaranteed to be a stable and permanent interface if the SLAB
>
> Debugging feature and "stable and permanent" just don't
> fit together. It's like requesting stable and permanent
> sysrq output.
Yeah, unfortuna
On Tue, Jan 01, 2008 at 04:45:21AM +0100, Bodo Eggert wrote:
> > udev-free != embedded.
>
> But UNIX=m == waste RAM and have an effectively b0rken system until the
> module is loaded.
Well, the system isn't necessarily totally broken. If you don't use
udev, then system will be crippled, but no
On Mon, Dec 24, 2007 at 11:21:14AM -0800, Christoph Lameter wrote:
>
> That is why there is a slabinfo tool that does all the nice formatting.
>
> Do a
>
> gcc -o slabinfo Documentation/vm/slabinfo.c
>
> Then run slabinfo instead of doing cat /proc/slabinfo
So two questions: why isn't -f the
On Sun, Dec 23, 2007 at 03:15:00PM +0100, Andi Kleen wrote:
> > Same here. In fact, I've always considered that procfs was for
> > humans while sysfs was for tools. sysfs reminds me too much the
> > unexploitable /devices in Solaris. With the proper tools, I think
> > we can do a lot with it, but i
On Sat, Dec 22, 2007 at 10:01:37AM -0800, Linus Torvalds wrote:
> Well, I do have to admit that I'm not a huge fan of /proc/slabinfo, and
> the fact that there hasn't been a lot of complaints about it going away
> does seem to imply that it wasn't a very important ABI.
>
> I'm the first to stand
On Fri, Dec 21, 2007 at 11:10:36AM -0500, Andrew Lutomirski wrote:
> > > Step 1: Boot a system without a usable entropy source.
> > > Step 2: add some (predictable) "entropy" from userspace which isn't a
> > > multiple of 4, so up to three extra bytes get added.
> > > Step 3: Read a few bytes of /d
On Thu, Dec 20, 2007 at 09:54:11PM +, Alan Cox wrote:
> > Kernel messages do not have to be terminated with a period.
>
> This piece of the document is wrong. It should also be changed. I've no
> idea how such a ludicrous statement ever got into the Coding Style but I
> have never seen it disc
On Wed, Dec 19, 2007 at 11:18:54PM -0500, Andrew Lutomirski wrote:
> I understand that there's no way that /dev/random can provide good
> output if there's insufficient entropy. But it still shouldn't leak
> arbitrary bits of user data that were never meant to be put into the
> pool at all.
Let's
On Thu, Dec 20, 2007 at 01:32:02AM -0800, Natalie Protasevich wrote:
> > The problem is that it appears to the casual observer as if they can
> > then add information to the bug through the web interface. But that
> > information will never be forwarded to the mailing list. Unless there's
> > a w
On Mon, Dec 17, 2007 at 10:58:54PM -0800, Arjan van de Ven wrote:
> Theodore Tso wrote:
>> On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote:
>>> which also gets bonus points for being totally unreadable, and thus 100%
>>> in the spirit of uuid's.
On Tue, Dec 18, 2007 at 02:39:00PM +1030, David Newall wrote:
>
> Thus, the entropy saved at shutdown can be known at boot-time. (You can
> examine the saved entropy on disk.)
>
If you can examine the saved entropy on disk, you can also introduce a
trojan horse kernel that logs all keystrokes an
On Tue, Dec 18, 2007 at 01:43:28PM +1030, David Newall wrote:
> On a server, keyboard and mouse are rarely used. As you've described it,
> that leaves only the disk, and during the boot process, disk accesses and
> timing are somewhat predictable. Whether this is sufficient to break the
> RNG
On Mon, Dec 17, 2007 at 07:52:53PM -0500, Andy Lutomirski wrote:
> It runs on a freshly booted machine (no
> DSA involved, so we're not automatically hosed), so an attacker knows the
> initial pool state.
Not just a freshly booted system. The system has to be a freshly
booted, AND freshly ins
On Mon, Dec 17, 2007 at 04:21:12PM -0800, Linus Torvalds wrote:
> which also gets bonus points for being totally unreadable, and thus 100%
> in the spirit of uuid's.
Heh. UUID's don't have to be readable; just universally unique. Code
on the other hand should be readable. :-)
If you want som
On Mon, Dec 17, 2007 at 01:36:31PM -0800, Arjan van de Ven wrote:
> Subject: [patch] terminate the oops printing with a defined string/uuid
> From: Arjan van de Ven <[EMAIL PROTECTED]>
>
> Right now, it's hard for automated tools to determine when an oops has
> ended; there's no clear marker for t
On Mon, Dec 17, 2007 at 08:30:05AM -0800, John Reiser wrote:
> >>[You have yet to show that...]
> >>There is a path that goes from user data into the pool.
>
> Note particularly that the path includes data from other users.
> Under the current implementation, anyone who accesses /dev/urandom
> is
On Sun, Dec 16, 2007 at 10:53:19PM +0100, Helge Deller wrote:
>
> FYI, we are currently discussing and testing this proposed patch to e2fsprogs
> off-list in Red Hat's bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=233471
Note that this bug is currently not publically visible. (You nee
On Fri, Dec 14, 2007 at 04:30:08PM -0800, John Reiser wrote:
> There is a path that goes from user data into the pool. This path
> is subject to manipulation by an attacker, for both reading and
> writing. Are you going to guarantee that in five years nobody
> will discover a way to take advantag
On Fri, Dec 14, 2007 at 12:45:23PM -0800, John Reiser wrote:
> > It's getting folded into the random number pool, where it will be
> > impossible to recover it unless you already know what was in the
> > pool. And if you know what's in the pool, you've already broken into
> > the kernel.
>
> The
On Wed, Dec 12, 2007 at 10:46:40PM +0100, Mariusz Kozlowski wrote:
> Hello,
>
> The unused code found in ext3_find_entry() is also present (and still
> unused)
> in the ext4_find_entry() code. This patch removes it. Compile tested only.
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTE
On Mon, Dec 10, 2007 at 05:35:25PM -0600, Matt Mackall wrote:
> > I must have missed this. Can you please explain again? For a layman it
> > looks like a paranoid application cannot read 500 Bytes from
> > /dev/random without blocking if some other application has previously
> > read 10 Kilobytes f
On Sun, Dec 09, 2007 at 11:05:20AM -0600, Matt Mackall wrote:
> Ahh, but this an attack on the output! You know only:
>
> pool' (including a fortuitously placed add_ptr)
>
> and from that, you can get all but 64 bits of pool. By 2**64 iterations of:
>
> pool = pool' + guess
> hash = SHA1(init
On Tue, Nov 20, 2007 at 06:00:12PM -0500, Theodore Tso wrote:
> Basically, the only way to solve this problem 100% in userspace would
> be with a userspace daemon running as a privileged user, and some kind
> of Unix domain socket.
>
> Patches to implement this in the e2fsprogs UUI
On Sat, Dec 08, 2007 at 11:43:37PM -0600, Matt Mackall wrote:
> > If you are trying to find the value of the 80 bits that were
> > extracted, and you know the current state of the pool, yes, you can
> > take the 96 bits that were changed after the last extraction, and try
> > all possible 2**96 com
On Sat, Dec 08, 2007 at 10:22:04PM -0600, Matt Mackall wrote:
>
> It did. My laptop didn't relay them through my smarthost and my domain
> has an SPF record.
Ah, yes:
http://homepages.tesco.net/~J.deBoynePollard/FGA/smtp-spf-is-harmful.html
On Sun, Dec 09, 2007 at 08:21:16AM +0200, Ismail Dönmez wrote:
> My understanding was if you can drain entropy from /dev/urandom any futher
> reads from /dev/urandom will result in data which is not random at all. Is
> that wrong?
Past a certain point /dev/urandom will stat returning results whi
On Sat, Dec 08, 2007 at 11:30:53PM +0100, Rafael J. Wysocki wrote:
> On Saturday, 8 of December 2007, Theodore Tso wrote:
> > However, as far as I am concerned, Ingo's patch, first posted to LKML
> > here: http://lkml.org/lkml/2007/11/16/66 should be listed as fixing
>
On Sat, Dec 08, 2007 at 06:40:17PM -0600, Matt Mackall wrote:
> I'm working on strengthening forward security for cases where the
> internals are exposed to an attacker. There are any number of
> situations where this can and does happen, and ensuring we don't
> expose ourselves to backtracking is
On Sat, Dec 08, 2007 at 05:21:00PM -0600, Matt Mackall wrote:
> random: improve variable naming, clear extract buffer
>
> - split the SHA variables apart into hash and workspace
> - rename data to extract
> - wipe extract and workspace after hashing
>
> diff -r 924f9a441236 drivers/char/random.c
On Sat, Dec 08, 2007 at 05:20:39PM -0600, Matt Mackall wrote:
> random: step more rapidly through the pool when adding and extracting
>
> Second, this patch spreads the mixing across the pool more rapidly by
> using a larger step. For our secondary pools, we'll be sure to touch
> both blocks with
On Sat, Dec 08, 2007 at 05:20:38PM -0600, Matt Mackall wrote:
> random: make backtracking attacks harder
>
> At each extraction, we change (poolbits / 16) + 32 bits in the pool,
> or 96 bits in the case of the secondary pools. Thus, a brute-force
> backtracking attack on the pool state is less dif
On Sat, Dec 08, 2007 at 05:20:17PM -0600, Matt Mackall wrote:
> random: do extraction before mixing
>
> If an attacker manages to capture the current pool state, she can
> determine the last 10 bytes extracted from the pool.
That's not true; we aren't just extracting data in the
__add_entropy_wo
On Sat, Dec 08, 2007 at 05:20:16PM -0600, Matt Mackall wrote:
> random: use xor for mixing
>
> With direct assignment, we can determine the twist table element used
> for mixing (the high 3 bits of the table are unique) and reverse a
> single step of mixing. Instead, use xor, which should also hel
On Sat, Dec 08, 2007 at 09:42:39PM +0100, Willy Tarreau wrote:
> I remember having installed openssh on an AIX machines years ago, and
> being amazed by the number of sources it collected entropy from. Simple
> commands such as "ifconfig -a", "netstat -i" and "du -a", "ps -ef", "w"
> provided a lot
On Sun, Dec 09, 2007 at 12:10:10AM +0200, Ismail Dönmez wrote:
> > As long as /dev/random is readable for all users there's no reason to
> > use /dev/urandom for a local DoS...
>
> Draining entropy in /dev/urandom means that insecure and possibly not random
> data will be used and well thats a se
On Sat, Dec 08, 2007 at 03:04:32PM -0500, Jeff Garzik wrote:
> That's a bit of a tangent on a tangent. :) Most people don't have a
> hardware RNG.
Actually, most Business class laptops from IBM/Lenovo, HP, Dell,
Fujitsu, and Sony laptops *do* have TPM chips that among other things,
contain a sl
On Sat, Dec 08, 2007 at 01:42:41AM -0800, Andrew Morton wrote:
> > Subject : snd_hda_intel 2.6.24-rc2 bug: interrupts don't always
> > work on Lenovo X60s
> > Submitter : Roland Dreier <[EMAIL PROTECTED]>
> > References : http://lkml.org/lkml/2007/11/8/255
> > http://b
On Sat, Dec 08, 2007 at 12:15:25PM -0600, Matt Mackall wrote:
>
> It might be better for us to just improve the pool initialization.
> That'll improve the out of the box experience for everyone.
>
Yeah, I agree. Although keep in mind, doing things like mixing in MAC
address and DMI information
On Sat, Dec 08, 2007 at 11:43:43AM -0600, Matt Mackall wrote:
> > Huh? What's the concern? All you are submitting is a list of
> > hardware devices in your system. That's hardly anything sensitive
>
> Using MAC addresses -does- de-anonymize things though and presumably
> anonymous collectio
On Sat, Dec 08, 2007 at 11:33:57AM -0600, Mike McGrath wrote:
>> Huh? What's the concern? All you are submitting is a list of
>> hardware devices in your system. That's hardly anything sensitive
>
> We actually had a very vocal minority about all of that which ended up
> putting us in the u
On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote:
> > BTW, You may be better off using "uuidgen -t" to generate the UUID in
> > the smolt RPM, since that will use 12 bits of randomness from
> > /dev/random, plus the MAC, address and timestamp. So even if there is
> > zero randomness in
On Wed, Dec 05, 2007 at 08:26:19AM -0600, Mike McGrath wrote:
>
> Ok, whats going on here is an issue with how the smolt RPM installs the
> UUID and how Fedora's Live CD does an install. It's a complete false alarm
> on the kernel side, sorry for the confusion.
BTW, You may be better off using
On Wed, Dec 05, 2007 at 01:29:12PM +0100, Marc Haber wrote:
> On Tue, Dec 04, 2007 at 05:18:11PM +0100, Adrian Bunk wrote:
> > On Tue, Dec 04, 2007 at 12:41:25PM +0100, Marc Haber wrote:
> > > While debugging Exim4's GnuTLS interface, I recently found out that
> > > reading from /dev/urandom deplet
On Tue, Dec 04, 2007 at 02:48:12PM -0600, Mike McGrath wrote:
> Alan Cox wrote:
>>> Here's the top 5:
>>>
>>>266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132
>>>336 810e7126-1c69-4aff-b8b1-9db0fa8aa15a
>>>402 c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f
>>>884 06e84493-e024-44b1-9b32-32d78af04039
>
1 - 100 of 364 matches
Mail list logo
