The only reason for sb_getblk() failing is if it can't allocate the
buffer_head. So ENOMEM is more appropriate than EIO. In addition,
make sure that the file system is marked as being inconsistent if
sb_getblk() fails.
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.ker
On Fri, Jan 18, 2013 at 01:47:48AM -0200, Herton Ronaldo Krzesinski wrote:
> > > By the description and looking at commit c278531d39, this change isn't
> > > needed for 3.0 or 3.4 kernels (anything <= 3.6), they don't contain
> > > commit c278531d39.
> >
> > Ah, good catch. Should this be reverte
Otherwise, ext4 file systems with the quota feature enable will get a
very confusing "No such process" error message if the quota code is
built as a mdoule and the quota_v2 module has not been loaded.
Signed-off-by: "Theodore Ts'o"
Cc: Jan Kara
Cc: stable@vger.kern
In addition, print the error returned from ext4_enable_quotas()
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/super.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 30651bd..0a6e9d5
On Mon, Jan 21, 2013 at 11:40:17AM +0100, Jan Kara wrote:
> On Mon 21-01-13 01:46:21, Ted Tso wrote:
> > Otherwise, ext4 file systems with the quota feature enable will get a
> > very confusing "No such process" error message if the quota code is
> > built as a mdoule and the quota_v2 module has no
On Mon, Jan 21, 2013 at 04:10:08PM +0100, Jan Kara wrote:
> Exactly. There shouldn't be any conflicts so just keep it in your tree.
> You can add to the patch:
> Acked-by: Jan Kara
Great, thanks.
BTW, do you have any plans to work on getting repquota support for
ocfs2 and ext4 with the interna
e last thing we do with the inode.
>
> CC: linux-e...@vger.kernel.org
> CC: "Theodore Ts'o"
> CC: stable@vger.kernel.org
> Reviewed-by: Carlos Maiolino
> Acked-by: Jeff Moyer
> Signed-off-by: Jan Kara
I've picked up t
super+0x22/0x49
[] deactivate_super+0x30/0x33
[] mntput_no_expire+0x107/0x10c
[] sys_umount+0x2cf/0x2e0
[] sys_oldumount+0x12/0x14
[] syscall_call+0x7/0xb
---[ end trace 6a954cc790501c1f ]---
jbd2_log_wait_commit: error: j_commit_request=-1289337090, tid=0
Signed-off-by: "Theodore Ts'o&q
- Ted
>From ed4fe107ccba4424a9a074b060172eb390691ffa Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Wed, 20 Mar 2013 09:42:11 -0400
Subject: [PATCH] ext4: fix data=journal fast mount/umount hang
In data=journal mode, if we unmount the file system before a
transaction has a chance to complete, when the j
On Wed, Jul 18, 2012 at 09:31:36AM +0100, Al Viro wrote:
> Duplicate caused, AFAICS, by mismerge in
> ff9cb1c4eead5e4c292e75cd3170a82d66944101>
> Cc: stable@vger.kernel.org
> Signed-off-by: Al Viro
Applied, thanks.
- Ted
--
To unsubscribe from this list:
ion. ]
Signed-off-by: H. Peter Anvin
Acked-by: Ingo Molnar
Cc: DJ Johnston
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
er a htree root
or a normal directory block and we have different csum
calculation for these 2 types, we have to choose the right
one in ext4_rename.
btw, it is found by xfstests 013.
Signed-off-by: Tao Ma
Signed-off-by: "Theodore Ts'o"
Acked-by: Darrick J. Wong
---
[ Sorry, I
e2fsprogs will be sent in another patch.
This is spotted by xfstests 117.
Signed-off-by: Tao Ma
Signed-off-by: "Theodore Ts'o"
Acked-by: Darrick J. Wong
---
[ Sorry, I forgot to tag these with stable@vger.kernel.org -- Ted ]
fs/ext4/xattr.c | 11 ---
1 file changed, 4 i
f1fc49860a50179
even though I forgot to mark them with a cc:stable@vger.kernel.org.
Many thanks!!
- Ted
On Tue, Jul 31, 2012 at 01:27:04PM -0400, Theodore Ts'o wrote:
> From: Tao Ma
>
> commit 41eb70dde42b2360074a559a6f1fc49860a
by: Maciej Żenczykowski
Reported-by: Marti Raudsepp
Tested-by: Fengguang Wu
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/extents.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index cd0c7ed..aabbb3f 100644
--- a/f
On Fri, Aug 31, 2012 at 11:28:59AM +0200, Jan Kara wrote:
> >
> > Is this problem known? Or is there a fix for 3.0.X available?
> From a quick look, processes are waiting for IO so it may be that your
> disk is just loaded... Did it start happening after some change? Or do you
> experience unexp
On Fri, Apr 05, 2013 at 04:18:15PM -0700, Todd Poynor wrote:
> Perhaps the better fix is to revert those additional changes and let
> the ext4 folks figure out what to do about the remaining atomic_reads.
>
> > And care to cc: the ext4 developers/maintainers when sending ext4
> > patches?
Can you
hence the
test matrix.
Signed-off-by: Lukas Czerner
Signed-off-by: "Theodore Ts'o"
So the 64-bit divides aren't in the upstream kernel because the code
in question is long gone in the mainline ext4 code. It looks like Cai
(who did the 3.0 backport) never tes
From: Dmitry Monakhov
Signed-off-by: Dmitry Monakhov
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/extents.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index c1c0094..fa85ce8 100644
--- a/fs
From: Dmitry Monakhov
Signed-off-by: Dmitry Monakhov
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/inode.c | 8
fs/ext4/mmp.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 6
Fox the Kconfig documentation for CONFIG_EXT4_DEBUG to match the
change made by commit a0b30c1229: ext4: use module parameters instead
of debugfs for mballoc_debug
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/Kconfig | 3 ++-
1 file changed, 2 insertions
Addresses-Red-Hat-Bugzilla: #913245
Reported-by: Eric Sandeen
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/resize.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index 08d2312..b27c96d 100644
--- a/fs/ext4/re
On Wed, May 01, 2013 at 02:55:11PM +0200, Jiri Kosina wrote:
> >
> > --
> > From: Jiri Kosina
> > Subject: random: fix accounting race condition with lockless irq
> > entropy_count update
>
> I see this hasn't been included even in the third (
On Mon, May 06, 2013 at 04:22:47PM +0800, Lingzhu Xiang wrote:
> commit 3f8a6411fbada1fa482276591e037f3b1adcf55b upstream.
>
> Backported for 3.8 and 3.9-stable. Reverted ext4_get_group_number in bd86298.
>
> From: Theodore Ts'o
>
> Addresses-Red-Hat-Bugzilla: #913
On Mon, May 06, 2013 at 06:38:25PM +0800, Lingzhu Xiang wrote:
> Yes, this patch failed to apply automatically for 3.9 and would fail
> for 3.8 and 3.4.
Ah, I didn't realize. Thanks for backporting it!
- Ted
--
To unsubscribe from this list: send the
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 log2(
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
s ASAP.
- Ted
commit 26de1ba5acc39f0ab57ce1ed523cb128e4ad73a4
Author: Theodore Ts'o
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 introduce
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, s
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 pat
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 specifi
the unexpected disconnection of external
disks. So let's back out this change while do more investigation...
Signed-off-by: "Theodore Ts'o"
Reported-by: Nix
Reported-by: Toralf Förster
Cc: stable@vger.kernel.org
---
fs/jbd2/journal.c | 5 -
1 file changed, 5 deletions
the unexpected disconnection of external
disks. So let's back out this change while do more investigation...
Signed-off-by: "Theodore Ts'o"
Reported-by: Nix
Reported-by: Toralf Förster
Cc: stable@vger.kernel.org
---
fs/jbd2/journal.c | 5 -
1 file changed, 5 deletions
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 3.6
I've bcc'ed stable@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 Th
tely FUBAR'ed and was calculating the checksum on the wrong data
> (for all but 1k block file systems, sigh).
>
> We just didn't notice because the checksum would be correctly set when
> the file system was unmounted cleanly. (Sigh).
>
> The following patch should
we're much better off using it in
xfer_secondary_pool() anyway.
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
drivers/char/random.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/char/random.c b/drivers
time needed to detect/configure the hardware
in question. ]
Signed-off-by: Linus Torvalds
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
drivers/char/random.c | 28
include/linux/random.h | 1 +
2 files changed, 29 insertions(+
Send the USB device's serial, product, and manufacturer strings to the
/dev/random driver to help seed its pools.
Cc: Linus Torvalds
Acked-by: Greg KH
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
drivers/usb/core/hub.c | 9 +
1 file changed, 9
he goal is to seed the pool rather than add
useful entropy.
Signed-off-by: Mark Brown
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
---
drivers/rtc/rtc-wm831x.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-wm831x.c b/
Cc: David Miller
Cc: Linus Torvalds
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
net/core/dev.c | 3 +++
net/core/rtnetlink.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 6df2140..bdd1e88 100644
--- a/net/c
The real-time Linux folks don't like add_interrupt_randomness() taking
a spinlock since it is called in the low-level interrupt routine.
This also allows us to reduce the overhead in the fast path, for the
random driver, which is the interrupt collection path.
Signed-off-by: "Theodore
a HW RNG
anyway.
For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
drivers/char/random.c | 29 -
include/linux/ran
From: Mark Brown
wm831x devices contain a unique ID value. Feed this into the newly added
device_add_randomness() to add some per device seed data to the pool.
Signed-off-by: Mark Brown
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
---
drivers/mfd/wm831x-otp.c | 8
1
y: J. Alex Halderman .
Signed-off-by: Linus Torvalds
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
drivers/char/random.c | 103 ++
drivers/mfd/ab3100-core.c | 2 -
include/linux/random.h| 2 +-
kernel/irq/handle.c
On Fri, Jul 06, 2012 at 06:02:18PM -0500, Jonathan Nieder wrote:
>
> Why cc: stable@? Does this fix a build error, oops, hang, data
> corruption, real security issue, or other critical "oh, that's not
> good" bug?
All of the /dev/random patches in this patch series that were marked
for the stabl
On Sat, Jul 07, 2012 at 10:11:22AM -0700, Kees Cook wrote:
> While very unlikely, it is possible for arch_get_random_long() to fail
> in the middle of the loop in xfer_secondary_pool(), which would mean
> that the loop could stop with only part of u.hwrand populated, leading
> to mix_pool_bytes() i
On Sun, Jul 08, 2012 at 02:06:46AM +0100, Ben Hutchings wrote:
>
> Surely the number of random bytes being added is i * sizeof(long), not
> sizeof(u.hwrand)?
>
Meh; Kees Cook has made the same observation. Basically, in the
unlikely case where RDRAND fails, we'll end up mixing in stack
garbage.
From: Yongqiang Yang
The resize code was needlessly writing the backup block group
descriptor blocks multiple times (once per block group) during an
online resize.
Signed-off-by: Yongqiang Yang
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/resize.c | 1
waste of perfectly good I/O bandwidth, to skip writing those
blocks for sparse bg's.
Signed-off-by: Yongqiang Yang
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/resize.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/ext4/resize.c b/fs
From: Yongqiang Yang
The resize code was needlessly writing the backup block group
descriptor blocks multiple times (once per block group) during an
online resize.
Signed-off-by: Yongqiang Yang
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/resize.c | 1
waste of perfectly good I/O bandwidth, to skip writing those
blocks for sparse bg's.
Signed-off-by: Yongqiang Yang
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/resize.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/ext4/resize.c b/fs
/0x44
[] vfs_write+0x7b/0xe6
[] sys_write+0x3b/0x64
[] syscall_call+0x7/0xb
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/inode.c | 4 ++--
fs/fs-writeback.c | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/inode.c
Hi,
I have a set of patches that are currently queued for merging for 3.6.
I didn't mark them for stable@vger.kernel.org, since they aren't a bug
fix, but rather a new feature. However, it occurs to me that this is a
feature that many enterprise/stable users would probably want.
The patches are
On Fri, Sep 21, 2012 at 05:12:05PM -0500, Eric Sandeen wrote:
> > - if (free_blocks < 2 * dirty_blocks)
> > - writeback_inodes_sb_if_idle(sb, WB_REASON_FS_FREE_SPACE);
> > + if ((free_blocks < 2 * dirty_blocks) &&
> > writeback_in_progress(sb->s_bdi))
> > + writeback_inodes
On Fri, Sep 21, 2012 at 04:02:09PM -0700, Greg Kroah-Hartman wrote:
>
> That sounds "nice", but it seems to be a feature, and doesn't meet the
> main requirements of the stable tree.
I thought you had said that some features had gone into the stable
kernel tree because distro's were shipping them
On Fri, Sep 21, 2012 at 07:53:22PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Sep 21, 2012 at 08:49:30PM -0400, Theodore Ts'o wrote:
> > On Fri, Sep 21, 2012 at 04:02:09PM -0700, Greg Kroah-Hartman wrote:
> > >
> > > That sounds "nice", but it s
On Thu, Sep 27, 2012 at 09:18:30PM +0400, Dmitry Monakhov wrote:
> Hmm... even this '!' patch is still not good. I've got that complain
> WARNING: at fs/fs-writeback.c:1316 writeback_inodes_sb_nr+0x1a3/0x200()
This WARN_ON checking to make sure the s_umount mutex is grabbed.
What kernel are you a
Ah, you're right. I *can* easily see the problem; somehow I just
didn't notice it, but when I look back at my test logs, it's
definitely there. I thought sb_start_write() took s_umount, but it
doesn't, because it was trying to solve the exact same lock ordering
problem. Drat
Unfortunately,
:00 2001
From: Theodore Ts'o
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
write(), ext4_page_mkwrite, and nilfs_page_mkwrite(), the
best way to solve this is to move the responsibility for calling
file_update_time() to its caller.
Signed-off-by: "Theodore Ts'o"
Cc: Jan Kara
Cc: KONISHI Ryusuke
Cc: stable@vger.kernel.org
---
NOTE: Since this is a 3.6 regression, I ma
Note: this fixes a failure in xfstests #215 for ext3 file systems
mounted using ext4 and ext4 file systems mounted with -o nodelalloc.
- Ted
On Sun, Sep 30, 2012 at 03:48:19PM -0400, Theodore Ts'o wrote:
> Commits 41c4d25f78c0 and 41c4d25f78c0 in
On Sun, Sep 30, 2012 at 12:50:02PM -0700, Jonathan Nieder wrote:
> Theodore Ts'o wrote:
>
> > Since __block_page_mkwrite() only has three years,
> > block_page_mkwrite(), ext4_page_mkwrite, and nilfs_page_mkwrite(), the
>
> years = callers?
Yes, thanks for poi
o its caller.
This problem was found via xfstests #215 with a file system mounted
with -o nodelalloc.
Signed-off-by: "Theodore Ts'o"
Cc: Jan Kara
Cc: KONISHI Ryusuke
Cc: stable@vger.kernel.org
Note: If this gets pushed to Linus before the merge window opens, I'll
drop the cc
On Wed, Nov 21, 2012 at 12:25:09PM -0800, Greg KH wrote:
>
> Ah, sorry, I had missed that. I've fixed that up in the patch and
> applied it now, thanks for telling me what I did wrong.
Thanks for fixing up the patch. It saved me the trouble of
resubmitting a fixed up patch; much appreciated!!
On Thu, Nov 29, 2012 at 11:02:39AM -0800, Darrick J. Wong wrote:
> On Thu, Nov 29, 2012 at 11:43:48AM +0100, Lukas Czerner wrote:
> > Commit fa77dcfafeaa6bc73293c646bfc3d5192dcf0be2 introduces block bitmap
> > checksum calculation into ext4_new_inode() in the case that block group
> > was uninitial
On Wed, Dec 12, 2012 at 04:17:42PM +0100, Jan Kara wrote:
> The following race is possible between start_this_handle() and someone
> calling jbd2_journal_flush().
>
> Process A Process B
> start_this_handle().
> if (journal->j_barrier_count) # false
> if (!journal-
denial of service
attack. (Not a big deal in practice, but professional paranoids worry
about such things, and have even been known to allocate CVE numbers
on occasion.)
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/namei.c | 3 ++-
1 file changed, 2 i
ON in this case. Take the i_mutex in
ext4_orphan_cleanup() to suppress this warning.
Reported-by: Alexander Beregalov
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/super.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ext4/super.c b/fs/ext4/s
On Fri, Jun 27, 2014 at 10:45:47PM -0400, Nick Krause wrote:
> Do any of you use the kernel Bugzilla? If you do I was wondering if we
> can clean it up.
> Otherwise I was wondering were I can get an accurate list of open
> bugs in the newest
> kernels.
Some subsystem maintainers use the kernel bu
On Sat, Jun 28, 2014 at 12:06:15PM -0400, Nick Krause wrote:
> Do all of you guys even care about cleaning up bugs? If
> you do it would be great if I get a reply to where I can get
> a up to date list of kernel bugs.
We care about fixing bugs. Most kernel devs don't really care about
maintaining
. Otherwise, there is the potential of a bad journal
checksum (if journal checksums are enabled), and of the file system
becoming inconsistent if we crash at exactly the wrong time.
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
---
fs/ext4/ialloc.c | 14 +++---
1 file chang
from the size of a block.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Maurizio Lombardi
> Signed-off-by: Theodore Ts'o
This is already in Linus's tree (commit b5b607785). I'm not sure why
you resent it?
- Ted
--
To unsubscri
We are spending a lot of time explaining to users what this error
means. Let's try to improve the message to avoid this problem.
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
---
fs/ext4/mballoc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Tue, Jul 08, 2014 at 09:03:48AM +0200, Lukáš Czerner wrote:
>
> It is a bit better, even though strictly speaking it's not
> right, because it is not block bitmap alone, but rather aggregation
> of block bitmap and preallocations. But for the user this is really
> an implementation detail they
39/0x50
[] ? __ext4_es_shrink+0x4f/0x2e0
[] ? kmem_cache_alloc+0x18b/0x1a0
[] __ext4_es_shrink+0x4f/0x2e0
[] ext4_es_insert_extent+0xc8/0x180
[] ext4_map_blocks+0x1c4/0x550
[] ext4_writepages+0x6d4/0xd00
...
Reported-by: Minchan Kim
Signed-off-by: Theodore Ts'o
Reported-by: Minchan Ki
-Google-Bug: #17142205
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
---
fs/ext4/namei.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index b147a67..ae7088b 100644
--- a/fs/ext4/namei.c
+++
mb_unload_buddy() call in
ext4_discard_allocated_blocks().
Google-Bug-Id: 16844242
Fixes: 86f0afd463215fc3e58020493482faa4ac3a4d69
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
---
fs/ext4/mballoc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 9560277
ork structure which wakes up the
CPU much more rarely compared to writeback_expire_centisecs.
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
---
fs/fs-writeback.c | 82 +++---
include/linux/fs.h | 1 +
2 files changed, 73 insertion
Add a tuning knob so we can adjust the dirtytime expiration timeout,
which is very useful for testing lazytime.
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
---
fs/fs-writeback.c | 11 +++
include/linux/writeback.h | 3 +++
kernel/sysctl.c | 8 ++
On Mon, Mar 16, 2015 at 03:34:12PM -0600, Andreas Dilger wrote:
> I wonder if something more lightweight could be added to avoid this
> problem? For example, we only care about this case if it has been
> going on for more than the lazytime interval (about a day), so the
> inode could store a 16-bi
On Tue, Mar 17, 2015 at 11:33:37AM +0100, Jan Kara wrote:
> Yes, something like this should be possible. But I wanted that to happen
> as a separate patch once we have everything working correctly. The code is
> subtle enough that I didn't want Ted to complicate it with further
> optimizations in
out it.
>
>
> From 00a1a053ebe5febcfc2ec498bd894f035ad2aa06 Mon Sep 17 00:00:00 2001
> From: Theodore Ts'o
> Date: Sun, 30 Mar 2014 10:20:01 -0400
> Subject: ext4: atomically set inode->i_flags in ext4_set_inode_flags()
>
> From: Theodore Ts'o
>
> co
On Mon, Mar 31, 2014 at 04:44:58PM -0700, Greg KH wrote:
> > OTOH, this is a security fix, and the bug has been reported and
> > outstanding for a while, so if you want to push this sooner, that's
> > fine.
>
> Yes, I'd prefer to take this as-is, and I'll take any "cleanups" later
> when they hit
re we update i_disksize. That way, we also keep the
raw_inode's i_disksize protected.
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
Oops, the first version was missing the commit description
fs/ext4/ext4.h | 17 -
fs/ext4/inode.c | 16
We haven't taken i_mutex yet, so we need to use i_size_read().
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 6db7f7d..bc76559 100644
also move the call to ext4_mark_inode_dirty() into
> > the i_data_sem's critical region, to be consistent with all of the
> > other places where we update i_disksize. That way, we also keep the
> > raw_inode's i_disksize protected.
> >
> > Signed-off-by: "
On Mon, Jan 19, 2015 at 01:00:03PM -0500, Peter Hurley wrote:
> >> --- a/drivers/tty/pty.c
> >> +++ b/drivers/tty/pty.c
> >> @@ -210,6 +210,9 @@ static int pty_signal(struct tty_struct *tty, int sig)
> >> {
> >> struct pid *pgrp;
> >>
> >> +if (sig != SIGINT || sig != SIGQUIT || sig !=
The some platforms (e.g., ARM) initializes their clocks as
late_initcalls for some unknown reason. So make sure
random_int_secret_init() is run all of the late_initcalls are run.
Cc: stable@vger.kernel.org
Signed-off-by: "Theodore Ts'o"
---
drivers/char/random.c | 3 +--
rate worse code since the C
compiler doesn't know the fixed relationship between these fields, but
that is somewhat unlikely.
Signed-off-by: H. Peter Anvin
Cc:
Signed-off-by: Theodore Ts'o
---
drivers/char/random.c | 39 +++
1 file changed,
ut
that multiply then would have to be turned into a 32*32 -> 64 multiply.
Signed-off-by: H. Peter Anvin
Cc: DJ Johnston
Cc:
Signed-off-by: Theodore Ts'o
---
drivers/char/random.c | 60 ---
1 file changed, 52 insertions(+), 8 deletions(-)
d
From: "H. Peter Anvin"
Allow fractional bits of entropy to be tracked by scaling the entropy
counter (fixed point). This will be used in a subsequent patch that
accounts for entropy lost due to overwrites.
Signed-off-by: H. Peter Anvin
Cc:
Signed-off-by: Theodore Ts'o
--
I've added the following changes to this patch since upon testing,
there were some uses of r->entropy_count that were not properly
converted from using fractional bits to bits.
- Ted
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 1547338..
On Mon, Oct 14, 2013 at 01:16:41PM -0700, gre...@linuxfoundation.org wrote:
> The patch below was submitted to be applied to the 3.11-stable tree.
>
> I fail to see how this patch meets the stable kernel rules as found at
> Documentation/stable_kernel_rules.txt.
This patch adds a new interface wh
On Mon, Oct 14, 2013 at 02:15:53PM -0700, Greg KH wrote:
> > This patch adds a new interface which allows architecture-specific
> > code to address a security issue with the random driver for those
> > platforms which define get_cycles() to return zero all the time. The
> > most important p[latfor
On Wed, Oct 16, 2013 at 07:03:19AM -0700, Greg KH wrote:
>
> That's fine to push it to Linus, but for stable, I can't take new
> "features" without any user of those calls, that wouldn't make sense,
> would it?
>
> How about when those MIPS changes get to Linus, you let
> stable@vger.kernel.org k
imate cause of the BUG_ON.
2) Incorrectly determining how many block groups contained contiguous
free blocks in ext4_alloc_group_tables().
3) Incorrectly setting the start of the next block range to be marked
in use after a discontinuity in setup_new_flex_group_blocks().
Signed-off-by: &quo
vdd /vdd
resize2fs /dev/vdd 8G
Signed-off-by: "Theodore Ts'o"
Cc: stable@vger.kernel.org
---
fs/ext4/resize.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index 69a6261..f3b84cd 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/
ngle_inode+0xc3/0x545
[] writeback_sb_inodes+0x21f/0x36d
...
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
---
fs/ext4/inode.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 0554b0b..263a46c 100644
-
On Mon, Jun 15, 2015 at 02:33:52PM +0200, Jan Kara wrote:
> Yeah, that's nasty. Thanks for debugging this! However I think your fix
> reintroduces the original deadlock issues. do_journal_get_write_access()
> can end up blocking waiting for jbd2 thread to finish a commit while jbd2
> thread may b
1 - 100 of 164 matches
Mail list logo
