0802]exit_to_usermode_loop+0x146/0x1a0
[ 850.995456]do_syscall_64+0x317/0x400
[ 850.999425]entry_SYSCALL_64_after_hwframe+0x49/0xbe
Signed-off-by: Debabrata Banerjee
---
mm/memcontrol.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/mm/me
Fixes:
commit 1e381f60dad9 ("ext4: do not allow journal_opts for fs w/o journal")
Instead of removing EXT4_MOUNT_JOURNAL_CHECKSUM from s_def_mount_opt as
I assume was intended, all other options were blown away leading to
_ext4_show_options() output being incorrect.
Signed-off-by:
y this or
other journal related flags should be removed from s_def_mount_opt
regardless, it is only used for comparison to display opts, and we
already made sure they couldn't be set.
Signed-off-by: Debabrata Banerjee
---
fs/ext4/super.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/
, or an entirely different namespace. In the latter
case, the pid is already hidden from you, thus these permission don't
matter.
CC: Eric W. Biederman
CC: Daniel Lezcano
Signed-off-by: Debabrata Banerjee
---
fs/proc/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, Jul 6, 2017 at 1:16 PM, Mel Gorman wrote:
>
> I'm still struggling to see how counters help when an agent that monitors
> for high CPU usage could be activated
>
I suspect Roman has the same problem set as us, the CPU usage is
either always high, high and service critical likely when some
On Thu, Jul 6, 2017 at 11:51 AM, Mel Gorman wrote:
>
> These counters do not actually help you solve that particular problem.
> Knowing how many allocations happened since the system booted doesn't tell
> you much about how many failed or why they failed. You don't even know
> what frequency they
On Thu, Jul 6, 2017 at 9:19 AM, Mel Gorman wrote:
> The alloc counter updates are themselves a surprisingly heavy cost to
> the allocation path and this makes it worse for a debugging case that is
> relatively rare. I'm extremely reluctant for such a patch to be added
> given that the tracepoints
Set appropriate macvlan interface status based on lower device and our
status. Can be up, down, or lowerlayerdown.
Signed-off-by: Debabrata Banerjee
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 2bcf1f3..0f4b000 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
Replace homegrown broadcast checks with faster defs from etherdevice.h
Signed-off-by: Debabrata Banerjee
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index b7c7027..27238f3 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -45,9
Don't attempt to send rlb updates for incomplete entries, which can't be
sent anyway.
Signed-off-by: Debabrata Banerjee
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 1b45378..b7c7027 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/n
Make sure multicast, broadcast, and zero mac's cannot be the output of rlb
updates, which should all be directed arps. Receive load balancing will be
collapsed if any of these happen, as the switch will broadcast.
Signed-off-by: Debabrata Banerjee
diff --git a/drivers/net/bonding/bond_al
Comment in tcp_cwnd_restart() was referencing the wrong RFC for the algorithm
it's implementing.
Signed-off-by: Debabrata Banerjee
---
net/ipv4/tcp_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 65caf8b..0c
nux-kernel@vger.kernel.org
cc: linux-fsde...@vger.kernel.org
Signed-off-by: Debabrata Banerjee
---
fs/proc/generic.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 317b726..89b20cc 100644
--- a/fs/proc/generic.c
+++ b/fs/proc
7;s a legitimate
reason to restrict the reading of these values it would be better if normal
users could fetch them.
Cc: Julian Anastasov
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Debabrata Banerjee
---
net/ipv4/tcp_metrics.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv4/tcp_metr
commit d23ff701643a4a725e2c7a8ba2d567d39daa29ea introduced netlink support for
the new tcp_metrics, however it restricted getting of tcp_metrics to root user
only. This is a change from how these values could have been fetched when in
the old route cache. Unless there's a legitimate reason to restr
On Mon, May 12, 2014 at 5:50 PM, Andrew Morton
wrote:
> On Mon, 12 May 2014 07:20:27 +0200 Fabian Frederick wrote:
>
>> This patch issues a flush in generic_file_fsync.
>> (Modern filesystems already do it)
>>
>> Behaviour can be reversed using /sys/devices/.../cache_type
>> or by calling __gener
if it fits or we should continue discarding.
v3: fix whitespace
v2: fix loop properly
CC: sta...@vger.kernel.org
Signed-off-by: Debabrata Banerjee
---
kernel/printk/printk.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/
if it fits or we should continue discarding.
CC: sta...@vger.kernel.org
Signed-off-by: Debabrata Banerjee
---
kernel/printk/printk.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index b1d255f..bc67990
ple it won't include the prefix len if the last line was a LOG_CONT
record, which however will be printed because there won't be a previous line.
This patch makes sure enough records are discarded to be under len.
CC: sta...@vger.kernel.org
Signed-off-by: Debabrata Banerjee
---
kernel/pri
On Tue, May 28, 2013 at 12:31 AM, Joe Perches wrote:
>
> I think the __alloc_skb alloc failure message is ok,
> but maybe there shouldn't be something "scary" like
> a dump_stack.
>
> Maybe this site should use a trivial debug error
> message like below instead.
The stack trace may or may not be
20 matches
Mail list logo
