On Wed, Apr 10, 2019 at 05:31:35AM +0100, Al Viro wrote:
> On Tue, Apr 09, 2019 at 09:04:15PM -0700, Eric Biggers wrote:
>
> > > What's to stop you from doing just that right now? You'd need to take
> > > care with barriers, but you'd need that anyway... As soon as ->i_link is
> > > set
> > >
On Tue, Apr 09, 2019 at 09:04:15PM -0700, Eric Biggers wrote:
> > What's to stop you from doing just that right now? You'd need to take
> > care with barriers, but you'd need that anyway... As soon as ->i_link is set
> > you'll get no more ->get_link() on that sucker, using the cached value
> >
On Tue, Apr 09, 2019 at 09:04:15PM -0700, Eric Biggers wrote:
> On Wed, Apr 10, 2019 at 04:44:14AM +0100, Al Viro wrote:
> > On Tue, Apr 09, 2019 at 07:58:08PM -0700, Eric Biggers wrote:
> >
> > > It could check a flag IOP_GET_LINK in ->i_opflags instead, so it would be
> > > the
> > > same
On Wed, Apr 10, 2019 at 04:44:14AM +0100, Al Viro wrote:
> On Tue, Apr 09, 2019 at 07:58:08PM -0700, Eric Biggers wrote:
>
> > It could check a flag IOP_GET_LINK in ->i_opflags instead, so it would be
> > the
> > same number of checks. See patch below.
>
> With that patch ->i_link is
On Tue, Apr 09, 2019 at 07:58:08PM -0700, Eric Biggers wrote:
> It could check a flag IOP_GET_LINK in ->i_opflags instead, so it would be the
> same number of checks. See patch below.
With that patch ->i_link is completely unused if ->get_link() is non-NULL,
so you get a method call on each
On Wed, Apr 10, 2019 at 02:39:34AM +0100, Al Viro wrote:
> On Tue, Apr 09, 2019 at 06:22:49PM -0700, Eric Biggers wrote:
>
> > > Non-NULL ->get_link() => DCACHE_SYMLINK_TYPE in ->d_flags =>
> > > d_is_symlink() true => step_into() progresses to pick_link().
> > >
> > > IOW, non-NULL ->get_link()
On Tue, Apr 09, 2019 at 06:22:49PM -0700, Eric Biggers wrote:
> > Non-NULL ->get_link() => DCACHE_SYMLINK_TYPE in ->d_flags =>
> > d_is_symlink() true => step_into() progresses to pick_link().
> >
> > IOW, non-NULL ->get_link() is what tells you that we have
> > a symlink there.
>
> I think
On Wed, Apr 10, 2019 at 02:04:25AM +0100, Al Viro wrote:
> On Tue, Apr 09, 2019 at 05:45:54PM -0700, Eric Biggers wrote:
> > On Wed, Apr 10, 2019 at 01:33:46AM +0100, Al Viro wrote:
> > > On Tue, Apr 09, 2019 at 04:35:44PM -0700, Eric Biggers wrote:
> > > > From: Eric Biggers
> > > >
> > > >
On Tue, Apr 09, 2019 at 05:45:54PM -0700, Eric Biggers wrote:
> On Wed, Apr 10, 2019 at 01:33:46AM +0100, Al Viro wrote:
> > On Tue, Apr 09, 2019 at 04:35:44PM -0700, Eric Biggers wrote:
> > > From: Eric Biggers
> > >
> > > Path lookups that traverse encrypted symlink(s) are very slow because
>
https://bugzilla.kernel.org/show_bug.cgi?id=203197
Chao Yu (c...@kernel.org) changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from
On Wed, Apr 10, 2019 at 01:33:46AM +0100, Al Viro wrote:
> On Tue, Apr 09, 2019 at 04:35:44PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Path lookups that traverse encrypted symlink(s) are very slow because
> > each encrypted symlink needs to be decrypted each time it's followed.
On Tue, Apr 09, 2019 at 04:35:44PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Path lookups that traverse encrypted symlink(s) are very slow because
> each encrypted symlink needs to be decrypted each time it's followed.
>
> Make encrypted symlinks faster by caching the decrypted
https://bugzilla.kernel.org/show_bug.cgi?id=203241
Bug ID: 203241
Summary: kernel BUG at fs/f2fs/segment.c:3222! and hangs on
sync
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=203239
--- Comment #2 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282249
--> https://bugzilla.kernel.org/attachment.cgi?id=282249=edit
run.sh
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203239
--- Comment #1 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282247
--> https://bugzilla.kernel.org/attachment.cgi?id=282247=edit
poc_15.c
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203239
Bug ID: 203239
Summary: kernel BUG at fs/f2fs/segment.c:3162! and hangs on
sync
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
From: Eric Biggers
Path lookups that traverse encrypted symlink(s) are very slow because
each encrypted symlink needs to be decrypted each time it's followed.
Make encrypted symlinks faster by caching the decrypted symlink target
in ->i_link. The first call to ->get_link() sets it; later calls
https://bugzilla.kernel.org/show_bug.cgi?id=203235
Bug ID: 203235
Summary: kernel BUG at fs/f2fs/segment.c:2131! and hangs on
sync
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=203235
--- Comment #1 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282243
--> https://bugzilla.kernel.org/attachment.cgi?id=282243=edit
poc_14.c
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203233
Bug ID: 203233
Summary: kernel BUG at fs/f2fs/segment.c:2102!
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
OS: Linux
Tree: Mainline
https://bugzilla.kernel.org/show_bug.cgi?id=203233
--- Comment #1 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282239
--> https://bugzilla.kernel.org/attachment.cgi?id=282239=edit
poc_13.c
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203231
--- Comment #1 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282235
--> https://bugzilla.kernel.org/attachment.cgi?id=282235=edit
poc_12.c
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203231
Bug ID: 203231
Summary: kernel BUG at fs/f2fs/segment.c:2079! and hangs on
sync
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=203229
Bug ID: 203229
Summary: kernel BUG at fs/f2fs/recovery.c:591! and hangs on
sync
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=203227
Bug ID: 203227
Summary: kernel BUG at fs/f2fs/recovery.c:549! and hangs on
sync
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=203225
Bug ID: 203225
Summary: kernel BUG at fs/f2fs/node.c:3073! and hangs on sync
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
OS: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=203223
--- Comment #1 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282225
--> https://bugzilla.kernel.org/attachment.cgi?id=282225=edit
poc_test_08.c
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203223
Bug ID: 203223
Summary: hangs on running program after mounting a crafted
image
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=203221
--- Comment #1 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282221
--> https://bugzilla.kernel.org/attachment.cgi?id=282221=edit
poc_07.c
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203221
Bug ID: 203221
Summary: kernel BUG at fs/f2fs/node.c:1279!
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
OS: Linux
Tree: Mainline
https://bugzilla.kernel.org/show_bug.cgi?id=203219
--- Comment #1 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282217
--> https://bugzilla.kernel.org/attachment.cgi?id=282217=edit
poc_06.c
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203219
Bug ID: 203219
Summary: kernel BUG at fs/f2fs/node.c:1183! and hangs on sync
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
OS: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=203217
Bug ID: 203217
Summary: kernel BUG at fs/f2fs/inode.c:707! and hangs
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
OS: Linux
Tree:
https://bugzilla.kernel.org/show_bug.cgi?id=203217
--- Comment #1 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282213
--> https://bugzilla.kernel.org/attachment.cgi?id=282213=edit
poc_test_05.c
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203215
Bug ID: 203215
Summary: failure at fs/f2fs/f2fs.h:2809/verify_blkaddr()!
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
OS: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=203213
--- Comment #1 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282207
--> https://bugzilla.kernel.org/attachment.cgi?id=282207=edit
poc_03.c
I missed the program.
Please compile this before starting to reproduce, like below.
-
https://bugzilla.kernel.org/show_bug.cgi?id=203213
Bug ID: 203213
Summary: kernel BUG at fs/f2fs/f2fs.h:2012 and hangs
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
OS: Linux
Tree:
https://bugzilla.kernel.org/show_bug.cgi?id=203211
Bug ID: 203211
Summary: Infinite error messages on mounting crafted image
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
OS: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=203209
--- Comment #1 from Jungyeon (jungy...@gatech.edu) ---
Created attachment 282199
--> https://bugzilla.kernel.org/attachment.cgi?id=282199=edit
poc_01.c
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203209
Bug ID: 203209
Summary: crash at f2fs_is_valid_blkaddr
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
OS: Linux
Tree: Mainline
https://bugzilla.kernel.org/show_bug.cgi?id=203169
--- Comment #4 from Jungyeon (jungy...@gatech.edu) ---
The image is f2fs image, but fuzzed from the normal f2fs image for testing.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203167
--- Comment #2 from Jungyeon (jungy...@gatech.edu) ---
I checked with CONFIG_F2FS_CHECK_FS option on, and it shows that f2fs mount
errors not crashing.
However, CONFIG_F2FS_CHECK_FS is not enabled by default, and I guess that there
is a high
https://bugzilla.kernel.org/show_bug.cgi?id=203197
Chao Yu (c...@kernel.org) changed:
What|Removed |Added
CC||c...@kernel.org
--- Comment
On Wed 2019-04-03 14:28:14, Sakari Ailus wrote:
> Ping.
>
> On Tue, Mar 26, 2019 at 02:35:10PM +0100, Petr Mladek wrote:
> > Linus,
> >
> > On Mon 2019-03-25 21:32:28, Sakari Ailus wrote:
> > > %pF and %pf are functionally equivalent to %pS and %ps conversion
> > > specifiers. The former are
https://bugzilla.kernel.org/show_bug.cgi?id=203197
Bug ID: 203197
Summary: kernel read fault at __is_cp_guaranteed
Product: File System
Version: 2.5
Kernel Version: 5.0.0
Hardware: All
OS: Linux
Tree:
Add F2FS_IOC_RESIZE_FROM_END for f2fs_compat_ioctl() as well.
Signed-off-by: Sahitya Tummala
---
fs/f2fs/file.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 42adfc2..0514935 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -3159,6 +3159,7 @@ long
The main area segs/secs/zones will be updated/changed after an
online resize. Hence, update the struct f2fs_stat_info as well
accordingly to show correct status in debugfs.
Signed-off-by: Sahitya Tummala
---
fs/f2fs/debug.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
NEW_MAIN_SECS() can be updated by f2fs_resize_from_end() path,
while get_victim_by_default() is running. Hence, protect all
references to NEW_MAIN_SECS() with seglist_lock mutex.
Signed-off-by: Sahitya Tummala
---
fs/f2fs/gc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
There can be a potential race between allocate_segment_for_resize() and
allocate_data_block(), resulting into two issues -
1. The allocate_data_block() can get a data block from a segment which
is currently being resized. This results in data being updated in an
outdated or already resized
On 2019/4/9 16:53, Randall Huang wrote:
> When we traverse xattr entries via __find_xattr(),
> if the raw filesystem content is faked or any hardware failure occurs,
> out-of-bound error can be detected by KASAN.
> Fix the issue by introducing boundary check.
>
> [ 38.402878] c7 1827 BUG:
Hi Randall,
On 2019/4/9 16:36, Randall Huang wrote:
> On Mon, Apr 08, 2019 at 08:14:43PM +0800, Chao Yu wrote:
>> On 2019/4/8 20:03, Chao Yu wrote:
>>> Hi Randall,
>>>
>>> On 2019/4/8 16:50, Randall Huang wrote:
When we traverse xattr entries via __find_xattr(),
if the raw filesystem
When we traverse xattr entries via __find_xattr(),
if the raw filesystem content is faked or any hardware failure occurs,
out-of-bound error can be detected by KASAN.
Fix the issue by introducing boundary check.
[ 38.402878] c7 1827 BUG: KASAN: slab-out-of-bounds in
f2fs_getxattr+0x518/0x68c
When we traverse xattr entries via __find_xattr(),
if the raw filesystem content is faked or any hardware failure occurs,
out-of-bound error can be detected by KASAN.
Fix the issue by introducing boundary check.
[ 38.402878] c7 1827 BUG: KASAN: slab-out-of-bounds in
f2fs_getxattr+0x518/0x68c
On Mon, Apr 08, 2019 at 08:14:43PM +0800, Chao Yu wrote:
> On 2019/4/8 20:03, Chao Yu wrote:
> > Hi Randall,
> >
> > On 2019/4/8 16:50, Randall Huang wrote:
> >> When we traverse xattr entries via __find_xattr(),
> >> if the raw filesystem content is faked or any hardware failure occurs,
> >>
54 matches
Mail list logo
