On 19.01.21 г. 7:05 ч., Chaitanya Kulkarni wrote:
> Signed-off-by: Chaitanya Kulkarni
> ---
> fs/btrfs/volumes.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index ee086fc56c30..836167212252 100644
> --- a/fs/btrfs/volum
;
> Signed-off-by: Wan Jiabing
Reviewed-by: Nikolay Borisov
On 17.03.21 г. 0:46 ч., Victor Erminpour wrote:
> Calling cc-option will use KBUILD_CFLAGS, which when lazy setting
> subdir-ccflags-y produces the following build error:
>
> scripts/Makefile.lib:10: *** Recursive variable `KBUILD_CFLAGS' \
> references itself (eventually). Stop.
>
> Us
On 6.12.20 г. 10:56 ч., Yun Levi wrote:
>> This, and the change above this, are not related to this patch so you
>> might not want to include them.
>
>> Also, why is this patch series even needed? I don't see a justification
>> for it anywhere, only "what" this patch is, not "why".
>
> I thin
On 9.03.21 г. 10:49 ч., kernel test robot wrote:
>
>
> Greeting,
>
> FYI, we noticed the following commit (built with gcc-9):
>
> commit: 5297199a8bca12b8b96afcbf2341605efb6005de ("btrfs: remove inode number
> cache feature")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
This is a leftover from 7f26482a872c ("locking/percpu-rwsem: Remove the
embedded rwsem")
Signed-off-by: Nikolay Borisov
---
V2:
* Add reference to commit which made the file useless.
kernel/locking/rwsem.h | 0
1 file changed, 0 insertions(+), 0 deletions(-)
delete mode 100
Hello,
I'm currently seeing latest Linus' master being somewhat broken w.r.t
krpobes. In particular I have the following test-case:
#!/bin/bash
mkfs.btrfs -f /dev/vdc &> /dev/null
mount /dev/vdc /media/scratch/
bpftrace -e 'kprobe:btrfs_sync_file {printf("kprobe: %s\n", kstack());}'
&>bpf-outpu
On 27.01.21 г. 15:57 ч., Michal Rostecki wrote:
> From: Michal Rostecki
>
> Before this change, the btrfs_get_io_geometry() function was calling
> btrfs_get_chunk_map() to get the extent mapping, necessary for
> calculating the I/O geometry. It was using that extent mapping only
> internally a
On 27.01.21 г. 17:24 ч., Masami Hiramatsu wrote:
> On Thu, 28 Jan 2021 00:13:53 +0900
> Masami Hiramatsu wrote:
>
>> Hi Nikolay,
>>
>> On Wed, 27 Jan 2021 15:43:29 +0200
>> Nikolay Borisov wrote:
>>
>>> Hello,
>>>
>>> I&#
On 28.01.21 г. 5:38 ч., Masami Hiramatsu wrote:
> Hi,
>
>
> Yeah, there is. Nikolay, could you try this tentative patch?
I can confirm that with this patch everything is working. I also applied
the following diff:
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 6c001
oduce the premature OOM killer issue
> which was originally addressed by the heuristic.
>
> As per David Chinner the xfs is doing similar thing since 2.6.15 already
> so ext4 is not the only affected filesystem. Moreover he notes:
> : For example: IO completion might requir
Hello,
I have a machine running kernel 3.13.3, in fact I have 3 such machines
which are connected via corosync in a cluster. On one of the machines
I observed the following lock-up:
Jul 26 06:01:14 shrek kernel: [ cut here ]
Jul 26 06:01:14 shrek kernel: WARNING: CPU:
On 07/15/2015 10:46 PM, Seth Forshee wrote:
> From: Andy Lutomirski
>
> If a process gets access to a mount from a different namespace user
> namespace, that process should not be able to take advantage of
> setuid files or selinux entrypoints from that filesystem.
> Technically, trusting mount
On 07/16/2015 11:00 PM, Mathieu Desnoyers wrote:
> Expose a new system call allowing threads to register a userspace memory
> area where to store the current CPU number. Scheduler migration sets the
> TIF_NOTIFY_RESUME flag on the current thread. Upon return to user-space,
> a notify-resume handl
ne_fast to also apply this for
dm backed devices.
Otherwise:
Reviewed-by: Nikolay Borisov
On 05/11/2016 09:38 AM, Nikolay Borisov wrote:
>
>
> On 05/11/2016 01:01 AM, Paolo Valente wrote:
>> When a bio is cloned, the newly created bio must be associated with
>> the same blkcg as the original bio (if BLK_CGROUP is enabled). If
>> this operation is not per
This patch changes the export attributes of the init_user_ns from
GPL-only to any modules. This needed so that non-gpl modules, such as
ZFS, utilize functions like i_(uid|gid)_(read|write).
Signed-off-by: Nikolay Borisov
---
kernel/user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Hello,
I'm currently dealing with a synchronization scheme which utilizes RCU
but I'm observing a race condition. So I have an rcu-enabled list, which
contains various entries. The add/delete paths of the list are protected
by a single spin_lock. I'm observing the following thing happening:
T1
Hello Josh,
I'd like to ask you whether objtool is supposed to produce a
warning when arch/x86/lib/csum-copy_64.o (produced from
arch/x86/lib/csum-copy_64.S). Since I cannot see any specific
usage of rbp for defining a stackframe. I'm chasing against
poor performance of a network benchmark an
On 12/14/2015 10:31 PM, Mike Snitzer wrote:
> On Mon, Dec 14 2015 at 3:11pm -0500,
> Nikolay Borisov wrote:
>
>> On Mon, Dec 14, 2015 at 5:31 PM, Mike Snitzer wrote:
>>> On Mon, Dec 14 2015 at 3:41P -0500,
>>> Nikolay Borisov wrote:
>>>
>
On 12/17/2015 05:33 PM, Tejun Heo wrote:
> Hello, Nikolay.
>
> On Thu, Dec 17, 2015 at 12:46:10PM +0200, Nikolay Borisov wrote:
>> diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c
>> index 493c38e08bd2..ccbbf7823cf3 100644
>> --- a/drivers/md/dm-thin.c
&g
_work item which
guarantees that on return the workitem is not running anymore.
Fixes: 905e51b39a555 ("dm thin: commit outstanding data every second")
Fixes: 85ad643b7e7e52 ("dm thin: add timeout to stop out-of-data-space
mode holding IO forever")
Signed-off-by: Nikolay Borisov
C
On 11/18/2015 04:58 PM, Al Viro wrote:
> On Wed, Nov 18, 2015 at 08:22:38AM -0600, Seth Forshee wrote:
>
>> But it still requires the admin set it up that way, no? And aren't
>> privileges required to set up those devices in the first place?
>>
>> I'm not saying that it wouldn't be a good idea t
On 12/11/2015 07:08 PM, Tejun Heo wrote:
> Hello, Nikolay.
>
> On Fri, Dec 11, 2015 at 05:57:22PM +0200, Nikolay Borisov wrote:
>> So I had a server with the patch just crash on me:
>>
>> Here is how the queue looks like:
>> crash> struct workqueue
Hello,
I'm using the attached script to perform some tests. However from time
to time I get the following results:
[root@kernighan lvm-race]# bash -x ./init_vg.sh
+ set -e
++ mktemp -u --tmpdir=. vgfile.
+ file=./vgfile.lCdz
++ mktemp -u testgrp-
+ group=testgrp-OgAz
++ mktemp -u thingrp-
On Mon, Dec 14, 2015 at 5:31 PM, Mike Snitzer wrote:
> On Mon, Dec 14 2015 at 3:41P -0500,
> Nikolay Borisov wrote:
>
>> Had another poke at the backtrace that is produced and here what the
>> delayed_work looks like:
>>
>> crash> struct delayed_work fff
On 09/09/2015 05:01 PM, Christoph Lameter wrote:
> On Wed, 9 Sep 2015, Nikolay Borisov wrote:
>
>> [root@kernighan vm]# ./slabinfo -da kmalloc-32
>> Cannot write to dma-kmalloc-32/sanity
>> [root@kernighan vm]# ./slabinfo -dF kmalloc-32
>> Cannot write to
Hello Tejun,
I've been observing the following crashes on kernel 4.2.6 :
73309.529940] BUG: unable to handle kernel NULL pointer dereference at
(null)
[73309.530238] IP: [] __queue_work+0xb3/0x390
[73309.530466] PGD 0
[73309.530681] Oops: [#1] SMP
[73309.530947] Modules linked
On 12/09/2015 06:08 PM, Tejun Heo wrote:
> Hello, Nikolay.
>
> On Wed, Dec 09, 2015 at 02:08:56PM +0200, Nikolay Borisov wrote:
>> 73309.529940] BUG: unable to handle kernel NULL pointer dereference at
>> (null)
>> [73309.530238] IP: [] __queue_work+0xb3/0
select_inode = ovl_d_select_inode,
> .d_revalidate = ovl_dentry_revalidate,
> .d_weak_revalidate = ovl_dentry_weak_revalidate,
> };
I wish I had seen this patch earlier than
https://marc.info/?l=linux-unionfs&m=145494313009959
Reviewed-by: Nikolay Borisov
Tested-by: Nikolay Borisov
On 02/16/2016 08:24 PM, Tejun Heo wrote:
> Signed-off-by: Tejun Heo
> Reported-and-tested-by: Tahsin Erdogan
> Link:
> http://lkml.kernel.org/g/caaeu0ancq7lgodvvgru-ou_o-6enii5ey0p1c26d1zzywkd...@mail.gmail.com
> Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback
>
ons, which allows querying the correct inode
when writing to an overlayed location, using a remote lower dir.
Fixes: daee0af5b522 ("overlayfs: Make f_path always point to the
overlay and f_inode to the underlay")
Signed-off-by: Nikolay Borisov
---
This took me quite a while to
On 02/15/2016 04:09 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> net/ipv4/igmp.c: In function 'igmp_group_added':
> net/ipv4/igmp.c:1227:14: warning: unused variable 'net' [-Wunused-vari
;
> -#endif
> }
> spin_unlock_bh(&pmc->lock);
> return err;
> @@ -2711,13 +2691,10 @@ static int igmp_mc_seq_show(struct seq_file *seq,
> void *v)
> char *querier;
> long delta;
>
> -#ifdef CONFIG_IP_MULTICAST
> - querier = IGMP_V1_SEEN(state->in_dev) ? "V1" :
> + querier = !IS_ENABLED(CONFIG_IP_MULTICAST) ? "NONE" :
> + IGMP_V1_SEEN(state->in_dev) ? "V1" :
> IGMP_V2_SEEN(state->in_dev) ? "V2" :
> "V3";
> -#else
> - querier = "NONE";
> -#endif
>
> if (rcu_access_pointer(state->in_dev->mc_list) == im) {
> seq_printf(seq, "%d\t%-10s: %5d %7s\n",
>
Reviewed-by: Nikolay Borisov
On 02/24/2016 07:09 PM, Konstantin Khlebnikov wrote:
> This might be unexpected but pages allocated for sbi->s_buddy_cache are
> charged to current memory cgroup. So, GFP_NOFS allocation could fail if
> current task has been killed by OOM or if current memory cgroup has no
> free memory left. Blo
On 02/25/2016 11:08 AM, Michal Hocko wrote:
> On Thu 25-02-16 11:01:32, Nikolay Borisov wrote:
>>
>>
>> On 02/24/2016 07:09 PM, Konstantin Khlebnikov wrote:
>>> This might be unexpected but pages allocated for sbi->s_buddy_cache are
>>> charged to curr
ARN_ON_ONCE(unlikely(gfp_flags & __GFP_NOFAIL) && (order > 1));
WARN_ON_ONCE already includes an unlikely in its definition:
http://lxr.free-electrons.com/source/include/asm-generic/bug.h#L109
> spin_lock_irqsave(&zone->lock, flags);
>
> page = NULL;
>
Reviewed-by: Nikolay Borisov
Hello,
On one of our servers we are observing deadlocks when fsync running. The
kernel version in question is: 3.12.28
We've managed to acquire a backtrace from one of the hanging processes:
PID: 21575 TASK: 883f482ac200 CPU: 24 COMMAND: "exim"
#0 [8824be1ab0e8] __schedule at fff
Hello,
get_next_ino would allocate a number between 0...2^32 - 1 to be used as
an inode number. The implementation of this mechanism relies on an
unsigned int which is 32 bits. On one server I'm observing that every
couple of months grsec complains that the percpu variable last_ino
overflows
Hello,
I can confirm that I'm also observing the same issue. Here is the output
of turbostat:
without hping running (Most of the time is spent in idle C6 state, which
is expected):
pk cor CPU%c0 GHz TSC SMI%c1%c3%c6%c7 CTMP PTMP
%pc2 %pc3 %pc6 %pc7 Pkg_W Cor
Hello
I can confirm that I'm also observing the same issue when running
turbostat. I've attached the respective turbostat log with and without
the hping syn flood running. I've also attached my kernel config.
It's evident that when the CPU is in c0 state (processing data) due to
the syn pac
s. The first user wins. Either the probe or the patch
> + is rejected when the handler is already in use by the other.
> +
> +
> + + Kprobes in the original function are ignored when the code is redirected
> +to the new implementation.
> +
> +There is a work in progress to add warnings about this situations.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4029c63d8a7d..0e7049688862 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6590,6 +6590,7 @@ F: kernel/livepatch/
> F: include/linux/livepatch.h
> F: arch/x86/include/asm/livepatch.h
> F: arch/x86/kernel/livepatch.c
> +F: Documentation/livepatch/
> F: Documentation/ABI/testing/sysfs-kernel-livepatch
> F: samples/livepatch/
> L: live-patch...@vger.kernel.org
>
It's a good starting point. Hopefully a bit of tweaking will make it
even more friendly to newcomers of livepatching (I have read the sources
but I'm in no way VERY familiar with it). I'm especially interested in
the relocation and current consistency model documentation.
Reviewed-by: Nikolay Borisov
On 04/06/2016 04:25 AM, David Rientjes wrote:
> The page_counter rounds limits down to page size values. This makes
> sense, except in the case of hugetlb_cgroup where it's not possible to
> charge partial hugepages.
>
> Round the hugetlb_cgroup limit down to hugepage size.
>
> Signed-off-by:
On 04/06/2016 10:26 AM, Nikolay Borisov wrote:
>
>
> On 04/06/2016 04:25 AM, David Rientjes wrote:
>> The page_counter rounds limits down to page size values. This makes
>> sense, except in the case of hugetlb_cgroup where it's not possible to
>> charge pa
Hello,
On a 4.4.1 kernel I observed the following crash:
[1157738.189104] BUG: unable to handle kernel NULL pointer dereference at
(null)
[1157738.189374] IP: [] __wake_up_common+0x2e/0x90
[1157738.189596] PGD 4382a6067 PUD 43827e067 PMD 0
[1157738.189901] Oops: [#1] SMP
[1157
On 03/28/2016 08:26 AM, js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> Major kmem_cache metadata in slab subsystem is synchronized with
> the slab_mutex. In SLAB, if some of them is changed, node's shared
> array cache would be freed and re-populated. If __kmem_cache_shrink()
> is called at th
On 04/01/2016 06:49 PM, Andy Lutomirski wrote:
> Sadly, hardware turbo mode buttons are few and far between in these
> degenerate times. Add a software control at /proc/sys/turbo_mode.
>
> Unfortunately, Linux graphical environments have become very
> heavy-weight and are essentially unusable o
eempt_disable();
> + pstat = this_cpu_ptr(&pcs->stats[stat]);
> + *pstat += cnt;
> + preempt_enable();
> +}
pstat = get_cpu_ptr(&pcs->stats[stat]);
*pstat += cnt;
put_cpu_ptr(&pcs->stats[stat]);
It will generate identical code but this one uses APIs, making the
intention clearer. But as I said this is just a minor nit.
you can add my Reviewed-by: Nikolay Borisov for this
particular patch.
Hello Jiri,
I think you should also add this patch:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2871c69e025e8bc507651d5a9cf81a8a7da9d24b
I hit this on 3.12.47 originally -
http://www.spinics.net/lists/dm-devel/msg24531.html
On 10/28/2015 03:51 PM, Jiri Slaby wrote
Switch ext4 to using sb_getblk_gfp with GFP_NOFS added, this fixes
possible deadlocks in the page writeback path.
Signed-off-by: Nikolay Borisov
---
fs/ext4/extents.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index
ments a sb_getblk_gfp with the only difference it can
accept user-provided GFP flags.
Signed-off-by: Nikolay Borisov
---
As per the discussion in this thread
(http://marc.info/?l=linux-ext4&m=143563347324528&w=2)
here are the patches which hopefully implement Ted's suggestion
On 07/02/2015 09:14 AM, Theodore Ts'o wrote:
> On Tue, Jun 30, 2015 at 09:26:49AM +0300, Nikolay Borisov wrote:
>> Switch ext4 to using sb_getblk_gfp with GFP_NOFS added, this fixes
>> possible deadlocks in the page writeback path.
>>
>> Signed-off-by: Nikolay Bori
Hi Jiry,
Maybe you would want to consider this:
https://patchwork.ozlabs.org/patch/459088/
It has already found its ways in other stable kernels, despite not being
cc'ed to stable.
Regards,
Nikolay
On 09/15/2015 05:22 PM, Jiri Slaby wrote:
> This is the start of the stable review cycle for the
Hello,
I've hit a rather strange hard lock up on one of my servers from the
page writeback path, the actual backtrace is:
[427149.717151] [ cut here ]
[427149.717553] WARNING: CPU: 23 PID: 4611 at kernel/watchdog.c:245
watchdog_overflow_callback+0x98/0xc0()
[427149.718
meaning "wait until the ipi handler has finished", which of course will
never
happen in the described situation.
Regards,
Nikolay
On 10/08/2015 02:46 PM, Nikolay Borisov wrote:
> Hello,
>
> I've hit a rather strange hard lock up on one of my servers from the
>
On 10/08/2015 05:34 PM, John Stoffel wrote:
> Great bug report, but you're missing the info on which kernel you're
This is on 3.12.47 (self compiled). It was evident on my initial post,
but I did forget to mention that in the reply. Also, I suspect even
current kernel are susceptible to this sin
ng on the bitlock it will
have its interrupts enabled, thus being able to respond to IPIs.
This eventually would allow memory allocation requiring draining of
the per cpu pages to succeed.
Signed-off-by: Nikolay Borisov
---
fs/ext4/page-io.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Signed-off-by: Nikolay Borisov
---
fs/buffer.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 82283ab..7109d6a 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -305,8 +305,8 @@ static void end_buffer_async_read(struct buffer_head *bh
On 10/09/2015 10:19 AM, Hillf Danton wrote:
>> @@ -109,8 +109,8 @@ static void ext4_finish_bio(struct bio *bio)
>> if (bio->bi_error)
>> buffer_io_error(bh);
>> } while ((bh = bh->b_this_page) != head);
>> -bit_spin_unlock
On 10/09/2015 10:37 AM, Hillf Danton wrote:
@@ -109,8 +109,8 @@ static void ext4_finish_bio(struct bio *bio)
if (bio->bi_error)
buffer_io_error(bh);
} while ((bh = bh->b_this_page) != head);
- bit_spin_unlock
On 10/08/2015 09:56 PM, John Stoffel wrote:
>>>>>> "Nikolay" == Nikolay Borisov writes:
>
> Nikolay> On 10/08/2015 05:34 PM, John Stoffel wrote:
>>> Great bug report, but you're missing the info on which kernel
>>> you're
>
On 10/09/2015 11:41 AM, Gilad Ben-Yossef wrote:
> On Oct 8, 2015 18:31, "Nikolay Borisov" wrote:
>>
>> Currently when bios are being finished in ext4_finish_bio this is done by
>> first disabling interrupts and then acquiring a bit_spin_lock.
> ...
>>
&g
Hello,
Today a colleague was testing something and while doing so he observed
the following crash:
jbd2_journal_bmap: journal block not found at offset 67 on dm-26-8
Aborting journal on device dm-26-8.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] jbd2_superb
rt to make filesystems mountable in non-init user
namespace and
an arbitrary user could potentially cause instability on the system?
Regards,
Nikolay
On Wed, Sep 30, 2015 at 8:12 PM, Darrick J. Wong
wrote:
> On Wed, Sep 30, 2015 at 04:35:49PM +0300, Nikolay Borisov wrote:
>> Hello,
On 24.09.19 г. 9:14 ч., Pavel Machek wrote:
> AFAICT, with current code user could pass something like "lzox" and
> still get "lzo" compression. Check string lengths to prevent that.
>
> Signed-off-by: Pavel Machek
>
> diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
> index b05b3
On 24.09.19 г. 1:57 ч., Navid Emamdoost wrote:
> In btrfs_mount_root the last error checking was not going to the error
> handling path. Fixed it.
>
> Signed-off-by: Navid Emamdoost
NAK
deactivate_locked_super actually calls btrfs_kill_super which in turn
calls generic_shutdown_super which d
On 11.07.19 г. 22:52 ч., Chris Mason wrote:
> On 11 Jul 2019, at 12:00, Nikolay Borisov wrote:
>
>> On 10.07.19 г. 22:28 ч., Tejun Heo wrote:
>>> From: Chris Mason
>>>
>>> The btrfs writepages function collects a large range of pages flagged
>>
On 23.01.19 г. 0:59 ч., Matthew Friday wrote:
> Signed-off-by: Matthew Friday
It seems you are using an outdated version of the code. When sending new
code always base it on misc-next branch from
https://github.com/kdave/btrfs-devel
> ---
> fs/btrfs/ioctl.c | 3 ---
> 1 file changed, 3 delet
On 28.01.19 г. 23:24 ч., Dennis Zhou wrote:
> Zstd compression requires different amounts of memory for each level of
> compression. The prior patches implemented indirection to allow for each
> compression type to manage their workspaces independently. This patch
> uses this indirection to impl
On 28.01.19 г. 23:24 ч., Dennis Zhou wrote:
> It is very easy to miss places that rely on a certain bitshifting for
> decyphering the type_level overloading. Make macros handle this instead.
>
> Signed-off-by: Dennis Zhou
Reviewed-by: Nikolay Borisov
On 28.01.19 г. 23:24 ч., Dennis Zhou wrote:
> This is in preparation for zstd compression levels. As each level will
> require different sized workspaces, workspaces_list is no longer a
> really fitting name.
>
> Signed-off-by: Dennis Zhou
Reviewed-by: Nikolay Borisov
&g
igned-off-by: Dennis Zhou
Reviewed-by: Nikolay Borisov albeit one minor nit
below.
> ---
> fs/btrfs/compression.c | 107 +++-
> fs/btrfs/compression.h | 3 +-
> fs/btrfs/ioctl.c| 2 +-
> fs/btrfs/tree-checker.c | 4 +-
> 4 fi
On 28.01.19 г. 23:24 ч., Dennis Zhou wrote:
> Make the workspace_manager own the interface operations rather than
> managing index-paired arrays for the workspace_manager and compression
> operations.
>
> Signed-off-by: Dennis Zhou
Reviewed-by: Nikolay Borisov
&g
will be the generic implementation for btrfs workspace
> management.
>
> Signed-off-by: Dennis Zhou
Reviewed-by: Nikolay Borisov
l.
>
> Signed-off-by: Dennis Zhou
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/compression.c | 31 ---
> fs/btrfs/compression.h | 7 ---
> fs/btrfs/lzo.c | 6 +++---
> fs/btrfs/zlib.c| 7 ---
> fs/btrfs/zstd.c
On 28.01.19 г. 23:24 ч., Dennis Zhou wrote:
> Currently, the only user of set_level() is zlib which sets an internal
> workspace parameter. As level is now plumbed into get_workspace(), this
> can be handled there rather than separately.
>
> This repurposes set_level() to bound the level passed
om the size of the workspace.
>
> Signed-off-by: Dennis Zhou
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/zstd.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/fs/btrfs/zstd.c b/fs/btrfs/zstd.c
> index 43f3be755b8c..a
On 28.01.19 г. 23:24 ч., Dennis Zhou wrote:
> The previous patch added generic helpers for get_workspace() and
> put_workspace(). Now, we can migrate ownership of the workspace_manager
> to be in the compression type code as the compression code itself
> doesn't care beyond being able to get a w
On 1.04.19 г. 16:24 ч., kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs: tree-checker:
> Verify dev item")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> in testcase:
; I've decided to put an end to it.
>
> If one of the above mentioned processes tries opening a file, return -EPERM
> indicating this process does not have the permission to open files on Linux
> anymore.
>
> Signed-off-by: Johannes Thumshirn
Ack-by: Nikolay Borisov
> ---
>
On 7.05.19 г. 10:36 ч., Andreas Schwab wrote:
> When a user mode process accesses an address in the vmalloc area
> do_page_fault tries to unlock the mmap semaphore when it isn't locked.
>
> Signed-off-by: Andreas Schwab
> ---
> arch/riscv/mm/fault.c | 3 ++-
> 1 file changed, 2 insertions(+),
On 7.05.19 г. 17:12 ч., Andreas Schwab wrote:
> On Mai 07 2019, Nikolay Borisov wrote:
>
>> At the very least the code under
>> no_context label could go into it's own function since it just kills the
>> process and never returns?
>
> This is not tr
On 26.07.19 г. 16:16 ч., Paul Menzel wrote:
> Dear Linux folks,
>
>
> On a Power 8 server
>
> Linux power 5.3.0-rc1+ #1 SMP Fri Jul 26 11:34:28 CEST 2019 ppc64le
> ppc64le ppc64le GNU/Linux
>
> Kmemleak reports the warnings below.
>
> ```
> $ sudo more /sys/kernel/debug/kmemleak
> unre
Hello Christoph,
5.3-rc1 crashes for me when run in qemu with scsi disks.
Quick investigation shows that the following triggers a BUG_ON:
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index e11b115dd0e4..4465e352b8dd 100644
--- a/include/linux/dma-mapping.h
+++ b/inclu
On 24.06.19 г. 8:52 ч., Christoph Hellwig wrote:
> Introduce two nicely abstracted helper, which can be moved to the
> iomap code later. Also use list_pop and list_first_entry_or_null
> to simplify the code a bit.
>
> Signed-off-by: Christoph Hellwig
> ---
> fs/xfs/xfs_aops.c | 66 ++
On 25.06.19 г. 13:14 ч., Christoph Hellwig wrote:
> On Mon, Jun 24, 2019 at 07:06:22PM +0300, Nikolay Borisov wrote:
>>> +{
>>> + struct list_headtmp;
>>> +
>>> + list_replace_init(&ioend->io_list, &tmp);
>>> + xfs_destroy
antees of the locking scheme and whether there is some silent
breakage lurking.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 10 +++---
fs/btrfs/disk-io.c | 39 +++
fs/btrfs/extent-tree.c | 35 ---
fs/btrfs/f
and vice-versa. Current implementation
actually favors Readers (that is snapshot creaters) to writers (nocow
writers of the filesystem).
Signed-off-by: Nikolay Borisov
---
fs/btrfs/Makefile | 2 +-
fs/btrfs/drw_lock.c | 71 +
fs/btrfs/drw_lock.h | 23
eUnlock(tid) begin
if threads[tid] = "write_locked" then
threads[tid] := "idle";
if ~\E thread \in 1..Len(threads): threads[thread] = "write_locked" then
lock_state := "idle"; \* we were the last write holder, everyone
el
antees of the locking scheme and whether there is some silent
breakage lurking.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 9 ++---
fs/btrfs/disk-io.c | 46 ++
fs/btrfs/extent-tree.c | 35
fs/btrfs
On 21.02.19 г. 22:25 ч., Dennis Zhou wrote:
> The timer function, zstd_reclaim_timer_fn(), reschedules itself under
> certain conditions. Switch to del_timer_sync() to ensure that the timer
> function hasn't rescheduled itself.
According to del_timer_sync it just waits for any concurrent invoca
ret" and make it to be void function.
>
> Signed-off-by: zhong jiang
Reviewed-by: Nikolay Borisov ---
> fs/btrfs/extent_map.c | 5 +
> fs/btrfs/extent_map.h | 2 +-
> 2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/ex
On 3.03.2018 02:24, Andrew Morton wrote:
> On Mon, 26 Feb 2018 11:54:30 +0200 Nikolay Borisov wrote:
>
>> We already get the block counts and the calculate the end block at the
>> beginning of the function. Let's use the local variables for consistency and
>&g
On 14.04.2018 00:14, Andrew Morton wrote:
> On Fri, 13 Apr 2018 13:28:23 -0700 Khazhismel Kumykov
> wrote:
>
>> shrink_dcache_parent may spin waiting for a parallel shrink_dentry_list.
>> In this case we may have 0 dentries to dispose, so we will never
>> schedule out while waiting for the par
ing, so this refactors these uses of max() to use the
> new const_max() instead.
>
> [1] https://lkml.org/lkml/2018/3/7/621
For the btrfs portion :
Reviewed-by: Nikolay Borisov
>
> Signed-off-by: Kees Cook
> ---
> drivers/input/touchscreen/cyttsp4_core.c | 2 +-
> fs/btrfs/
On 19.04.2018 08:32, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in mainline kernel and at least dates back to v4.16 .
>
> It's rather rare error and happens when running xfstests.
Yeah, so this is something which only recently was characterised as
leaking delalloc inodes. I can easily r
On 8.12.2016 03:40, Eric W. Biederman wrote:
> Nikolay Borisov writes:
>
>> Gentle ping, now that rc1 has shipped and Jan's sysctl concern hopefully
>> resolved.
>
> After getting slowed down by some fixes I am now taking a hard look at
> your patch in the h
On 8.12.2016 08:58, Nikolay Borisov wrote:
>
>
> On 8.12.2016 03:40, Eric W. Biederman wrote:
>> Nikolay Borisov writes:
>>
>>> Gentle ping, now that rc1 has shipped and Jan's sysctl concern hopefully
>>> resolved.
>>
>> After getting
2000 2820a478
> [] el1_irq+0xb8/0x130 arch/arm64/kernel/entry.S:486
> [< inline >] arch_local_irq_restore
> ./arch/arm64/include/asm/irqflags.h:81
> [] rcu_idle_exit+0x64/0xa8 kernel/rcu/tree.c:1030
> [< inline >] cpuidle_id
On 20.01.2017 20:05, Eric W. Biederman wrote:
> Nikolay Borisov writes:
>
>> On 20.01.2017 15:07, Dmitry Vyukov wrote:
>>> Hello,
>>>
>>> I've got the following deadlock report while running syzkaller fuzzer
>>> on eec0d3d065bfcdf9cd5f56dd2a
101 - 200 of 378 matches
Mail list logo
