On Sun, Jan 14, 2001 at 08:10:45PM +0100, W. Michael Petullo wrote:
In serial.c, you seem to perform a check by writing to a possible
modem's interrupt enable register and reading the result. This seems to
be one of the points at which the auto-configuration process occasionally
fails.
Date: Tue, 06 Feb 2001 17:37:12 -0500
From: Ed Schulz [EMAIL PROTECTED]
One editorial correction: Our PCI host-controller modem is based on the
Mars DSP1646 or 1648, not the Venus DSP1673. Venus modems include the
controller function, so require no special Linux code to work.
On Fri, Mar 09, 2007 at 04:56:32PM +1100, Rusty Russell wrote:
__builtin_types_compatible_p() has been around since gcc 2.95, and we
don't use it anywhere. This patch quietly fixes that.
Signed-off-by: Rusty Russell [EMAIL PROTECTED]
Is your clock set correctly? Looks like this mail was
There is a newly updated ext4 patchset available at:
http://www2.kernel.org/pub/linux/kernel/people/tytso/ext4-patches
and
http://www2.kernel.org/git/?p=linux/kernel/git/tytso/ext4.git
Compared to 2.6.20-ext4-1, I've removed the the i_version patch, since
they had numerous
I was going through my set of kernel patches that I've cherry picked on
LKML for my private kernel, and I noticed this hasn't gotten merged into
mainline yet. The original thread was here:
http://lkml.org/lkml/2007/10/27/61
and addressed a panic after a umount reported by Sebastian
Hi all, some of you may have noticed have received mail bounces from
mail that you sent me from [EMAIL PROTECTED] that referenced failure
to deliver mail to [EMAIL PROTECTED], for example:
[EMAIL PROTECTED]... Deferred: Connection timed out with thunk.org.
Message could not be delivered for 3
I've just released 2.6.24-rc1-ext4-1. It removes patches accepted by
Linus and adds a number of cleanup patches. It also adds support for
storing i_blocks in units of filesystem blocks instead of 512 byte
sectors to eliminate one stupid (and easy to fix) large file scalability
limit.
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git for_linus
These are mostly bug fixes that we've found since the last pull request.
The one non-bugfix change is that I've added a sanity check to assure
that production ext3 filesystems don't get
fix for large block support
ext4: remove read-inode from defrag code,replace with ext4_iget()
Theodore Ts'o (2):
ext4: Stable/Unstable boundary
ext4: New inode allocation for FLEX_BG meta-data groups.
fs/buffer.c |3 +-
fs/ext4/Makefile
On Sun, Oct 28, 2012 at 04:18:59PM +0900, Akinobu Mita wrote:
Use random32_get_bytes() to generate 16 bytes of pseudo-random bytes.
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Since your patch is going to allow users to set the random seed, it
means that what had previously been a bad
On Mon, Oct 29, 2012 at 05:51:37PM -0400, Justin Piszcz wrote:
What happened afterwards?
It did eventually complete.
How much memory do you have in your system?
32GB memory/32GB swap
Did the system continue, and did the sync command (I presume you ran
sync from the command line?)
I recently upgraded to 3.6.3, and my Lenovo X230 has stopped being able
to work with an HP ZR30w 30 2560x1600 display. I saw the following
messages in the dmesg:
[drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail!
[drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!
.. which I
On Tue, Oct 30, 2012 at 09:49:58AM +0800, Huang Ying wrote:
The uuid_le/be_gen() in lib/uuid.c has set UUID variants to be DCE,
that is done in __uuid_gen_common() with b[8] = (b[8] 0x3F) | 0x80.
Oh, I see, I missed that.
To deal with random number generation issue, how about use
On Tue, Oct 30, 2012 at 04:55:22PM +0200, Lasse Kärkkäinen wrote:
Apparently there has been little or no development on urandom even
though the device is in widespread use for disk shredding and such
use. The device emits data at rather slow rate of 19 MB/s even on
modern hardware where other
On Wed, Oct 31, 2012 at 12:20:04AM +0800, Tekkaman Ninja wrote:
This is a Chinese translated version of
Documentation/arm/kernel_user_helpers.txt
Signed-off-by: Fu Wei tekkamanni...@gmail.com
I wonder if it woiuld be a good idea to note the git commit id of the
kernel version that was used
On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote:
[1] drm-intel-next-queued branch at
git://people.freedesktop.org/~danvet/drm-intel
Hmm, actually not. Either drm-intel-fixes branch, or Linus' master.
Confirmed, the drm-intel-fixes branch from Daniel's tree
On Wed, Oct 31, 2012 at 09:35:37AM +0800, Huang Ying wrote:
The intention of lib/uuid.c is to unify various UUID related code, and
put them in same place. In addition to UUID generation, it provide some
other utility and may provide/collect more in the future. So do you
think it is a good
On Tue, Oct 30, 2012 at 08:12:39PM +0900, Akinobu Mita wrote:
How about prandom32_get_bytes_state() and prandom32_get_bytes() instead?
I agree with your suggestion. I'll rename them and try again.
By the way, should we also rename the existing random32() and
prandom32() in the
On Wed, Oct 31, 2012 at 12:06:19PM +0100, Dave Martin wrote:
What's the best way of making sure that changes in the source document
propagate to translated versions?
It might be enough to put a note in the source document to remind people
to check for the extistence of translated versions
On Fri, Nov 02, 2012 at 03:10:05AM +0200, Lasse Kärkkäinen wrote:
Thank you for your answers, they should be very helpful for someone
who is actually blanking or shredding their disks. However, I am
just genuinely interested on why is no better CSPRNG algorithm used
in the kernel (is it simply
/1053019
https://bugzilla.kernel.org/show_bug.cgi?id=47731
Signed-off-by: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com
Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: Brad Figg brad.f...@canonical.com
Cc: sta...@vger.kernel.org
--
To unsubscribe from this list: send the line
On Mon, Jul 23, 2012 at 04:03:14PM +0800, Wang Sheng-Hui wrote:
In the check code above, if orig_start != donor_start, we would
return -EINVAL. So here, orig_start should be equal with donor_start.
Remove the redundant check here.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
Applied,
On Thu, Sep 27, 2012 at 01:31:28PM -0700, Hugh Dickins wrote:
Kernel build with CONFIG_DEBUG_SLAB or CONFIG_SLUB_DEBUG slub_debug=FPZ
gives me kernel BUG at fs/ext4/extents_status.c:142! That's the
BUG_ON(es-start + es-len es-start) in extent_status_end() called
from ext4_es_insert_extent().
On Thu, Sep 27, 2012 at 02:05:00PM -0700, Hugh Dickins wrote:
Hi Ted,
mmotm (or next) now gives me lots of WARNING at fs/fs-writeback.c:1312 from
writeback_inodes_sb_nr(). That's WARN_ON(!rwsem_is_locked(sb-s_umount))
(some useful safety from hch) in writeback_inodes_sb_nr().
Your commit
From: Theodore Ts'o ty...@mit.edu
Date: Thu, 27 Sep 2012 23:12:48 -0400
Subject: [PATCH v2] ext4: fix potential deadlock in ext4_nonda_switch()
In ext4_nonda_switch(), if the file system is getting full we used to
call writeback_inodes_sb_if_idle(). The problem is that we can be
holding i_mutex
On Wed, Oct 03, 2012 at 01:29:15PM -0700, Linus Torvalds wrote:
On Wed, Oct 3, 2012 at 1:05 PM, Kees Cook k...@outflux.net wrote:
3.6 introduced link restrictions:
Hmm. If this causes problems for others, I suspect we need to turn it
off by default.
It's a nice security thing, but
On Thu, Oct 04, 2012 at 12:23:41AM +0200, Matthias Schniedermeyer wrote:
Personally i would have been bitten by this change, because for years i
have used a symlink in /tmp (which has the sticky bit) to a directory
somewhere else for historical reasons. But as i was aware of this change
i
On Thu, Oct 04, 2012 at 03:32:35PM +0200, Christoph Anton Mitterer wrote:
When seeding the kernels entropy cache (which is then ultimately used
for /dev/random), e.g. by (semi-)TRNGs like haveged[0],
audio-entropyd[1], Simtec’s Entropy Key[2] or friends... can one spoil
the randomness by
On Fri, Oct 05, 2012 at 09:51:55AM +0100, Iain Fraser wrote:
I understand the interrupts and softirq's run in interrupt context (
as opposed to process context ). But what I
don't understand is why you cannot sleep in interrupt context?
Consider what happens with nested locks (and yes, we
On Fri, Oct 05, 2012 at 11:16:12AM -0700, Anatol Pomozov wrote:
Hi, AlViro
Is any reason why this change is ignored? For me it looks like a
straightforward bugfix.
A little bit of context for this change. We at Google work on a test
framework that shows how kernel behaves under memory
for the same bg
Theodore Ts'o (19):
ext4: collapse a single extent tree block into the inode if possible
ext4: don't load the block bitmap for block groups which have no space
ext4: add max_dir_size_kb mount option
jbd2: check return value of blkdev_issue_flush()
ext4
On Mon, Oct 08, 2012 at 02:41:31AM +0200, Christoph Anton Mitterer wrote:
I just wondered because I remembered David Shaw (one of the main
developers from gpg) to imply[0] some time ago, that an evil entropy
source would actually be a problem:
I've looked at his message, I didn't see any
Ping?
On Tue, Oct 30, 2012 at 04:32:21PM -0400, Theodore Ts'o wrote:
On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote:
[1] drm-intel-next-queued branch at
git://people.freedesktop.org/~danvet/drm-intel
Hmm, actually not. Either drm-intel-fixes branch, or Linus' master
On Sat, Nov 03, 2012 at 11:21:58AM +0100, Daniel Vetter wrote:
Well, we know for sure that fdi link training is broken - it doesn't match
at all what the spec says we should do. I've been working on this lately,
since in quite a few circumstances the link train fails without the
relevent
On Mon, Nov 05, 2012 at 09:03:48PM +0100, Pavel Machek wrote:
Well, using data journalling with ext3/4 may do what you want. If you
don't do any fsync, the changes will get written every 5 seconds when
the automatic journal sync happens (and sub-4k writes will also get
Hmm. But that
On Mon, Nov 05, 2012 at 05:37:02PM -0500, Richard Hipp wrote:
Per the docs: Only the superuser or a process possessing the
CAP_SYS_RESOURCE capability can set or clear this attribute. That
prevents most applications that run SQLite from being able to take
advantage of this, since most such
On Tue, Nov 06, 2012 at 05:11:17PM -0800, Kees Cook wrote:
Hrm, I don't like this. get_random_int() specifically says: Get a
random word for internal kernel use only. The intent of AT_RANDOM is
for userspace pRNG seeding (though glibc currently uses it directly
for stack protector and pointer
On Thu, Nov 08, 2012 at 01:32:38AM +0100, Stephan Mueller wrote:
However, due to the fact that jiffies provides very few entropy, the
event value provides (almost) none, the majority of entropy comes from
the processor cycles. Assuming that the processor cycles increase once
per nanosecond,
On Tue, Nov 06, 2012 at 10:42:42AM -0500, Jarod Wilson wrote:
The value stored in last_data must be primed for FIPS 140-2 purposes. Upon
first use, either on system startup or after an RNDCLEARPOOL ioctl, we
need to take an initial random sample, store it internally in last_data,
then pass
On Mon, Oct 29, 2012 at 03:32:08PM +0800, Zhao Hongjiang wrote:
From: Zhao Hongjiang zhaohongji...@huawei.com
Clean the duplicate code on ext4_fill_super cause the bellow
also have it.
Signed-off-by: Zhao Hongjiang zhaohongji...@huawei.com
Applied, thanks!
I used the commit description:
On Sun, Nov 04, 2012 at 08:59:31PM -0500, Luming Yu wrote:
Back to July of this year, I sent the first round of the tool.
Now I've polished it a little bit.
The patch is the fist step to test some basic hardware functions like
TSC to help people understand if there is any hardware latency as
On Thu, Nov 08, 2012 at 03:06:14PM +, Nix wrote:
On 4 Nov 2012, Linus Torvalds stated:
Perhaps notable just because of the noise it caused in certain
circles, there's the ext4 bitmap journaling fix for the issue that
caused such a ruckus. It's a tiny patch and despite all the noise
On Mon, Oct 15, 2012 at 07:46:02PM +0200, Toralf Förster wrote:
Even with current stable kernel 3.6.2 I sometimes get those syslog messages :
2012-10-15T19:37:58.401+02:00 n22 kernel: EXT4-fs error (device sdb3):
ext4_mb_generate_buddy:741: group 436, 22902 clusters in bitmap, 22901 in gd
On Sun, Oct 21, 2012 at 01:29:35PM +0200, richard -rw- weinberger wrote:
Every kernel developer has his own wrapper script to make qemu usable.
IMHO it's time to add such a script to the kernel tree.
One observation I'll make is that for many people, what you want to do
is a *lot* more than
26de1ba5acc39f0ab57ce1ed523cb128e4ad73a4
Author: Theodore Ts'o ty...@mit.edu
Date: Tue Oct 23 18:15:22 2012 -0400
jbd2: fix a potential fs corrupting bug in jbd2_mark_journal_empty
Fix a potential file system corrupting bug which was introduced by
commit eeecef0af5ea4efd763c9554cf2bd80fc4a0efd3: jbd2: don't write
Just to follow up (mostly for ext4 developers). After talking to Eric
via irc, it appears he thought it was sufficient to check (s_start ==
0) from commit 24bcc89c7e, which was authored by Jan Kara. (Which we
now need to audit very carefully, although it's been in the upstream
kernel since 3.4,
On Wed, Oct 24, 2012 at 12:06:21AM +0100, Nix wrote:
I note that the patch is in the latest stable releases of 3.4.x and
3.5.x, which are IIRC end-of-lifed. I'd say that if your patch does
indeed fix it, this justifies pushing out new releases of both these
stable kernels with just this patch
Toralf,
Are you using any kind of special mount options on your usb stick?
Thanks,
- Ted
--
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
On Tue, Oct 23, 2012 at 08:50:22PM -0400, Nick Bowler wrote:
Hi folks,
I just saw an ext4 oops on one of my machines after a couple months of
uptime, on Linux 3.5.2. I doubt I will be able to reproduce the problem
easily so I'm just posting this in case anyone can tell what's going on.
superblock when if its empty
If journal-s_start is zero, we may not update journal-s_sequence when
it might be needed. (But we at the moement we can't see how this could
lead to the reported fs corruptions.)
commit cb57108637e01ec2f02d9311cedc3013e96f25d4
Author: Theodore Ts'o ty
Just to confirm, the ext4 lock_super removal is commit 07724f98978a,
and Linus has already pulled it into his tree.
- Ted
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Tue, Oct 09, 2012 at 01:01:24PM +0200, Lukáš Czerner wrote:
Do not get me wrong, I do not think it is worth to wait for vendors
to come to their senses, but it is worth constantly reminding that
we *need* this kind of information and those heuristics are not
feasible in the long run anyway.
On Tue, Oct 09, 2012 at 02:53:26PM -0500, Jooyoung Hwang wrote:
I'd like you to refer to the following link as well which is about
mobile workload pattern.
http://www.cs.cmu.edu/~fuyaoz/courses/15712/report.pdf
It's reported that in Android there are frequent issues of fsync and
most of them
On Tue, Oct 09, 2012 at 02:37:00PM -0700, Kent Overstreet wrote:
Honestly: I wouldn't bother. Nothing of consequence uses cancel.
I have an RFC patch series that tears it out. Let me polish that up
send it out, I'll cc: you.
Even better :)
I've been looking at aio locking the past
On Wed, Oct 10, 2012 at 02:20:51PM -0700, Zach Brown wrote:
I sympathize, but the reality is that the current infrastructure
is very bad and no one is using it.
It's not like we're getting rid of the syscall. I'll be behaving
exactly as it does today: returning the error code that
On Wed, Oct 24, 2012 at 07:31:57PM +0200, Toralf Förster wrote:
Are you using any kind of special mount options on your usb stick?
nope
Thanks, we're trying to get a reliable repro of this failure, and so
every bit of data helps... I've cc'ed you on the other thread, and if
you could try
On Wed, Oct 24, 2012 at 11:53:47AM -0400, Justin Piszcz wrote:
The problem which we are currently trying to investigate was
reportedly introduced in v3.6.1. So far that's about how we know; we
have two users who have reported it, but I and other ext4 developers
haven't been able to reproduce
On Wed, Oct 24, 2012 at 09:45:47PM +0100, Nix wrote:
It occurs to me that it is possible that this bug hits only those
filesystems for which a umount has started but been unable to complete.
If so, this is a relatively rare and unimportant bug which probably hits
only me and users of slow
On Wed, Oct 24, 2012 at 09:13:01PM +0200, Jannis Achstetter wrote:
As a normal linux user I'm interested in the practical things to do
now to avoid data loss. I'm running several systems with 3.6.2 and ext4.
Fearing loss of data:
- Is there a way to see whether the journal of a specific
On Thu, Oct 25, 2012 at 12:27:02AM +0100, Nix wrote:
- /sbin/reboot -f of running system
- Journal replay, no problems other than the expected free block
count problems. This is not such a severe problem after all!
- Normal shutdown, but a 60 second pause after lazy umount, more
On Tue, Oct 23, 2012 at 03:53:11PM -0400, Vladislav Bolkhovitin wrote:
Yes, SCSI has full support for ordered/simple commands designed
exactly for that task: to have steady flow of commands even in case
when some of them are ordered.
SCSI does, yes --- *if* the device actually implements
On Wed, Oct 24, 2012 at 03:03:00PM -0700, da...@lang.hm wrote:
Like what is being described for sqlite, loosing the tail end of the
messages is not a big problem under normal conditions. But there is
a need to be sure that what is there is complete up to the point
where it's lost.
this is
On Thu, Oct 25, 2012 at 12:18:47AM -0500, Nico Williams wrote:
By trusting fsync(). And if you don't care about immediate Durability
you can run the fsync() in a background thread and mark the associated
transaction as completed in the next transaction to be written after
the fsync()
On Thu, Oct 25, 2012 at 02:03:25PM +0100, Alan Cox wrote:
I doubt they care. The profit on high end features from the people who
really need them I would bet far exceeds any other benefit of giving it to
others. Welcome to capitalism 8)
Yes, but it's a question of pricing. If they had
On Wed, Oct 24, 2012 at 11:58:49PM -0700, da...@lang.hm wrote:
The frustrating thing is that when people point out how things like
sqlite are so horribly slow, the reply seems to be well, that's
what you get for doing so many fsyncs, don't do that, when there is
a 'problem' like the KDE config
I've been thinking about this some more, and if you don't have a lot
of time, perhaps the most important test to do is this. Does the
chance of your seeing corrupted files in v3.6.3 go down if you run
3.6.3 with commit 14b4ed22a6 reverted? Keep your current
configuration, using nobarrier, et.
On Thu, Oct 25, 2012 at 06:39:30PM +0200, Toralf Förster wrote:
After a lot of file operations (Gentoo emerging, kernel build, git
pulls, ...) I s2disk the system (that with the external USB drive)
yesterday, wake it up today, rebooted it -
and had to manually repair the file system, because
On Thu, Oct 25, 2012 at 11:03:13AM -0700, da...@lang.hm wrote:
I agree, this is why I'm trying to figure out the recommended way to
do this without needing to do full commits.
Since in most cases it's acceptable to loose the last few chunks
written, if we had some way of specifying ordering,
On Thu, Oct 25, 2012 at 08:11:12PM -0400, Ric Wheeler wrote:
Sending this just to you two to avoid embarrassing myself if I
misread the thread, but
Can we reproduce this with any other hardware RAID card? Or with MD?
There was another user who reported very similar corruption using
On Thu, Oct 25, 2012 at 11:12:48AM -0400, Naoya Horiguchi wrote:
+ /* Lost data. Handle as critical fs error. */
+ bh = head = page_buffers(page);
+ do {
+ if (buffer_dirty(bh) !buffer_delay(bh)) {
+ block = bh-b_blocknr;
+
On Fri, Oct 26, 2012 at 04:55:01PM +, Luck, Tony wrote:
I think that we know that the file *is* corrupted, not just potentially.
We probably know the location of the corruption to cache-line granularity.
Perhaps better on systems where we have access to ecc syndrome bits,
perhaps worse
On Fri, Oct 26, 2012 at 09:37:08PM +0100, Nix wrote:
I can reproduce this on a small filesystem and stick the image somewhere
if that would be of any use to anyone. (If I'm very lucky, merely making
this offer will make the problem go away. :} )
I'm not sure the image is going to be that
This looks very different. The symptoms are quite different, and it's
most likely that an unclean shutdown is involved. In your case,
you're doing clean shutdowns, with some suspend/resume cycles thrown
in. Also, kernel version 3.5.5 doesn't have the commits that were
added between 3.6.1 and
This isn't the first time that journal_checksum has proven problematic.
It's a shame that we're stuck between two error-inducing stools here...
The problem is that it currently bails out be aborting the entire
journal replay, and the file system will get left in a mess when it
does that. It's
I've bcc'ed sta...@vger.kernel.org, LKML, and greg-kh, since I suspect
they aren't interested in all of these details... we'll keep this on
linux-ext4 for sanity's sake.
On Sat, Oct 27, 2012 at 01:15:42AM +0200, Martin wrote:
sorry for the repetition, but Theodore Ts'o asked me to re-post
On Fri, Oct 26, 2012 at 10:19:21PM +0100, Nix wrote:
prevent unwary civilians from coming across the feature and saying,
oooh, shiny! and turning it on. :-(
Or having it turned on by default either, which seems to be the case
now.
Huh? It's not turned on by default. If you mount with
On Fri, Oct 26, 2012 at 09:54:53PM -0400, Vladislav Bolkhovitin wrote:
What different in our positions is that you are considering storage
as something you can connect to your desktop, while in my view
storage is something, which stores data and serves them the best
possible way with the best
On Sat, Oct 27, 2012 at 10:00:46AM +0200, Toralf Förster wrote:
otherwise booting an EXT4 image won't work b/c the root fs can't be
mounted read-write - and as a side effect no syslog messages might
point the user to this issue (at least in my setup) ...
This is only a problem on 32-bit
On Sat, Oct 27, 2012 at 01:45:25PM +0100, Nix wrote:
Ah! it's turned on by journal_async_commit. OK, that alone argues
against use of journal_async_commit, tested or not, and I'd not have
turned it on if I'd noticed that.
(So, the combinations I'll be trying for effect on this bug are:
On Fri, Oct 26, 2012 at 10:24:23PM +, Luck, Tony wrote:
Well, we could set a new attribute bit on the file which indicates
that the file has been corrupted, and this could cause any attempts to
open the file to return some error until the bit has been cleared.
That sounds a lot better
On Sun, Oct 28, 2012 at 05:02:17PM -0400, Justin Piszcz wrote:
Hello,
Any idea what happened here (during a backup)?
A sync system call took longer than two mintues. Why that happened,
it's harder to say. It's a warning, though, and not a fatal panic or
kernel oops.
How much memory do you
...@esperi.org.uk
Signed-off-by: Eric Sandeen sand...@redhat.com
Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: sta...@vger.kernel.org
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 4facdd2..575afac 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -725,6 +725,10
every time. With this fix it survives
many iterations.
Reported-by: Nix n...@esperi.org.uk
Signed-off-by: Eric Sandeen sand...@redhat.com
Signed-off-by: Theodore Ts'o ty...@mit.edu
Cc: sta...@vger.kernel.org
diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 4facdd2
On Sun, Oct 28, 2012 at 09:24:19PM -0500, Eric Sandeen wrote:
Yeah, I knew it wasn't ;) I did resend
[PATCH] ext4: fix unjournaled inode bitmap modification
which is a bit more involved.
Yeah, sorry, I didn't see your updated patch at first, since this mail
thread is one complicated tangle.
On Mon, Oct 29, 2012 at 12:16:32PM +1100, Dave Chinner wrote:
Except that there are filesystems that cannot implement such flags,
or require on-disk format changes to add more of those flags. This
is most definitely not a filesystem specific behaviour, so any sort
of VFS level per-file state
On Sun, Oct 28, 2012 at 09:35:58PM -0500, Eric Sandeen wrote:
Yeah, seems that way.
Then your simpler version is probably the way to go.
If you have a chance, could you do me a favor and test my -v3 version
of the patch? It should work just as well as yours, but I'm getting
paranoid in my
On Mon, Oct 29, 2012 at 03:37:05AM -0700, Andi Kleen wrote:
Agreed, if we're going to add an xattr, then we might as well store
I don't think an xattr makes sense for this. It's sufficient to keep
this state in memory.
In general these error paths are hard to test and it's important
to
On Sun, Oct 28, 2012 at 04:18:58PM +0900, Akinobu Mita wrote:
/**
+ * prandom32_get_bytes - get the requested number of pseudo-random bytes
+ * @state: pointer to state structure holding seeded state.
+ * @buf: where to copy the pseudo-random bytes to
+ * @bytes: the requested number
On Sun, Nov 11, 2012 at 09:34:16AM +, James Bottomley wrote:
Anybody who does enforcement will tell you that you begin with first
hand proof of a violation. That means obtain the product and make sure
it's been modified and that a request for corresponding source fails.
In this case,
On Sun, Nov 11, 2012 at 10:15:02AM -0500, Bradley M. Kuhn wrote:
Andy's initial email ended with the request: Please explain. Thus,
Andy's email seemed designed to seek facts, which I think is a
reasonable and good thing to do here. Meanwhile, the facts *still*
aren't clear here yet.
...
On Wed, Nov 14, 2012 at 04:24:48PM +1100, Stephen Rothwell wrote:
So, where did we get to? I *think* the consensus was that the KVM tool
did not need to be in the kernel tree, right? In which case:
1) I need to remove the kvmtool tree from linux-next
2) the same code needs to
On Mon, Oct 15, 2012 at 04:43:27PM -0500, Larry Finger wrote:
The value for LINUX_VERSION_CODE was not updated for kernel 3.7-rc1.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
version.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
Index:
On Mon, Oct 15, 2012 at 11:42:55PM +0200, Jiri Kosina wrote:
The module parameter that turns debugging mode (which basically means
printing a few extra lines during runtime) is in '#if 0' block. Forcing
everyone who would like to see how entropy is behaving on his system to
rebuild seems to
On Mon, Oct 15, 2012 at 11:43:29PM +0200, Jiri Kosina wrote:
Fix the following warnings in formatting debug output:
drivers/char/random.c: In function ‘xfer_secondary_pool’:
drivers/char/random.c:827: warning: format ‘%d’ expects type ‘int’, but
argument 7 has type ‘size_t’
On Sat, Sep 29, 2012 at 12:47:04PM -0700, H. Peter Anvin wrote:
-static struct poolinfo {
+static const struct poolinfo {
+int poolshift; /* log2(POOLBITS) */
int poolwords;
int tap1, tap2, tap3, tap4, tap5;
Poolshift is duplicated information; it's just
On Mon, Oct 15, 2012 at 09:45:23PM -0700, H. Peter Anvin wrote:
Or we could compute poolwords (and poolbits, and poolbytes) from it,
since shifts generally are cheap. I don't strongly care, whatever your
preference is.
We are already calculating poolbits from poolwords:
#define POOLBITS
I've just released the 2.6.23-rc7-ext4-1; it's largely identical to
2.6.23-rc6-ext4-1 except that I've synchronized patches and patch names
with patches that Andrew had pulled into 2.6.23-rc7-mm1.
It's available in the standard place:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
From: Aneesh Kumar K.V [EMAIL PROTECTED]
Signed-off-by: Mingming Cao [EMAIL PROTECTED]
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
fs/jbd/journal.c |2 +-
fs/jbd2/journal.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
From: Mingming Cao [EMAIL PROTECTED]
Convert kmalloc to kzalloc() and get rid of the memset().
Signed-off-by: Mingming Cao [EMAIL PROTECTED]
---
fs/ext4/xattr.c |3 +--
fs/jbd2/journal.c |3 +--
fs/jbd2/transaction.c |3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
From: Aneesh Kumar K.V [EMAIL PROTECTED]
Convert bg_inode_bitmap and bg_inode_table to bg_inode_bitmap_lo
and bg_inode_table_lo. This helps in finding BUGs due to
direct partial access of these split 64 bit values
Also fix one direct partial access
Signed-off-by: Aneesh Kumar K.V [EMAIL
1 - 100 of 3948 matches
Mail list logo
