On Wed, Jun 27, 2018 at 11:06:14AM -0400, Pavel Tatashin wrote:
> On Wed, Jun 27, 2018 at 10:15 AM Herton R. Krzesinski
> wrote:
> > Thanks, I'll try it. It'll probably work since I tried memory_reserve
> > but "hacking" it at e820__register_nosave_regions, any
On Wed, Jun 27, 2018 at 11:06:14AM -0400, Pavel Tatashin wrote:
> On Wed, Jun 27, 2018 at 10:15 AM Herton R. Krzesinski
> wrote:
> > Thanks, I'll try it. It'll probably work since I tried memory_reserve
> > but "hacking" it at e820__register_nosave_regions, any
'll probably work since I tried memory_reserve
but "hacking" it at e820__register_nosave_regions, anyway I'll confirm
it here.
>
> Thank you,
> Pavel
> On Wed, Jun 27, 2018 at 3:35 AM Michal Hocko wrote:
> >
> > This smells like an issue Naoya was seeing I guess (Cc
'll probably work since I tried memory_reserve
but "hacking" it at e820__register_nosave_regions, anyway I'll confirm
it here.
>
> Thank you,
> Pavel
> On Wed, Jun 27, 2018 at 3:35 AM Michal Hocko wrote:
> >
> > This smells like an issue Naoya was seeing I guess (Cc
On Tue, Jun 26, 2018 at 04:50:27PM -0400, Pavel Tatashin wrote:
> Herton,
>
> Thank you for analysis, could you please attach the config that you are using.
Sure, the config file is attached.
>
> Thank you,
> Pavel
> On Tue, Jun 26, 2018 at 4:42 PM Herton R. Krzesinski
On Tue, Jun 26, 2018 at 04:50:27PM -0400, Pavel Tatashin wrote:
> Herton,
>
> Thank you for analysis, could you please attach the config that you are using.
Sure, the config file is attached.
>
> Thank you,
> Pavel
> On Tue, Jun 26, 2018 at 4:42 PM Herton R. Krzesinski
Hi,
While running proc01 test from ltp, or as I later found out if you just read
kpagecount ("cat /proc/kpagecount > /dev/null"), I started to get the following
oops on latest kernels (4.17+) in a specific system:
[ 112.926100] general protection fault: [#1] SMP PTI
[ 112.926691] CPU: 1
Hi,
While running proc01 test from ltp, or as I later found out if you just read
kpagecount ("cat /proc/kpagecount > /dev/null"), I started to get the following
oops on latest kernels (4.17+) in a specific system:
[ 112.926100] general protection fault: [#1] SMP PTI
[ 112.926691] CPU: 1
temporary location in the build process).
Be flexible and allow the prefixed path to which we install man pages to be
changed with the INSTALL_MAN_PATH environment variable (and use the same
default as other similar variables like INSTALL_HDR_PATH).
Signed-off-by: Herton R. Krzesinski <
temporary location in the build process).
Be flexible and allow the prefixed path to which we install man pages to be
changed with the INSTALL_MAN_PATH environment variable (and use the same
default as other similar variables like INSTALL_HDR_PATH).
Signed-off-by: Herton R. Krzesinski
On Tue, Dec 15, 2015 at 04:05:09PM -0200, Herton R. Krzesinski wrote:
> On Tue, Dec 15, 2015 at 09:36:26AM -0800, Peter Hurley wrote:
> > > since in this
> > > case any of the tty->driver_data can be stale, due to all references/
> > > files being closed before
On Tue, Dec 15, 2015 at 04:05:09PM -0200, Herton R. Krzesinski wrote:
> On Tue, Dec 15, 2015 at 09:36:26AM -0800, Peter Hurley wrote:
> > > since in this
> > > case any of the tty->driver_data can be stale, due to all references/
> > > files being closed before
On Tue, Dec 15, 2015 at 11:52:14AM -0800, Peter Hurley wrote:
> On 12/15/2015 11:23 AM, Herton R. Krzesinski wrote:
> > On Tue, Dec 15, 2015 at 04:05:09PM -0200, Herton R. Krzesinski wrote:
> >> On Tue, Dec 15, 2015 at 09:36:26AM -0800, Peter Hurley wrote:
> >>>
>
On Tue, Dec 15, 2015 at 04:05:09PM -0200, Herton R. Krzesinski wrote:
> On Tue, Dec 15, 2015 at 09:36:26AM -0800, Peter Hurley wrote:
> >
> >
> > > Signed-off-by: Herton R. Krzesinski
> > > Cc:
> >
> > Afaict, the stable tag goes back to the orig
On Tue, Dec 15, 2015 at 09:28:28AM -0800, Peter Hurley wrote:
> On 12/15/2015 08:36 AM, Herton R. Krzesinski wrote:
> > On Tue, Dec 15, 2015 at 08:17:56AM -0800, Peter Hurley wrote:
> >>> I also expect in a rare case where all ptmx references are gone/closed,
> >>
On Tue, Dec 15, 2015 at 09:36:26AM -0800, Peter Hurley wrote:
> Hi Herton,
>
> On 12/14/2015 07:29 PM, Herton R. Krzesinski wrote:
> > pty_unix98_shutdown allows a potential use after free of inode from
> > slave tty->driver_data: if final pty close is called with slave
&
On Tue, Dec 15, 2015 at 08:17:56AM -0800, Peter Hurley wrote:
> > I also expect in a rare case where all ptmx references are gone/closed,
> > this also
> > could happen on final close when the master tty is given to
> > pty_unix98_shutdown.
>
> This logic I'm not following. If the pty master is
On Tue, Dec 15, 2015 at 09:36:26AM -0800, Peter Hurley wrote:
> Hi Herton,
>
> On 12/14/2015 07:29 PM, Herton R. Krzesinski wrote:
> > pty_unix98_shutdown allows a potential use after free of inode from
> > slave tty->driver_data: if final pty close is called with slave
&
On Tue, Dec 15, 2015 at 08:17:56AM -0800, Peter Hurley wrote:
> > I also expect in a rare case where all ptmx references are gone/closed,
> > this also
> > could happen on final close when the master tty is given to
> > pty_unix98_shutdown.
>
> This logic I'm not following. If the pty master is
On Tue, Dec 15, 2015 at 04:05:09PM -0200, Herton R. Krzesinski wrote:
> On Tue, Dec 15, 2015 at 09:36:26AM -0800, Peter Hurley wrote:
> >
> >
> > > Signed-off-by: Herton R. Krzesinski <her...@redhat.com>
> > > Cc: <sta...@vger.kernel.org>
> >
&
On Tue, Dec 15, 2015 at 09:28:28AM -0800, Peter Hurley wrote:
> On 12/15/2015 08:36 AM, Herton R. Krzesinski wrote:
> > On Tue, Dec 15, 2015 at 08:17:56AM -0800, Peter Hurley wrote:
> >>> I also expect in a rare case where all ptmx references are gone/closed,
> >>
On Tue, Dec 15, 2015 at 11:52:14AM -0800, Peter Hurley wrote:
> On 12/15/2015 11:23 AM, Herton R. Krzesinski wrote:
> > On Tue, Dec 15, 2015 at 04:05:09PM -0200, Herton R. Krzesinski wrote:
> >> On Tue, Dec 15, 2015 at 09:36:26AM -0800, Peter Hurley wrote:
> >>>
>
Hi,
recently I got a report of a crash at pty_unix98_shutdown. after analyzing the
issue, I managed to create a small reproducer:
$ cat test.sh
#!/bin/sh
while true; do
find /sys
./dopty
echo 2 > /proc/sys/vm/drop_caches
ps aux
sleep 40
done
$ cat
already
freed inode.
The fix here is to keep a reference on the opened master ptmx inode.
We maintain the inode referenced until the final pty_unix98_shutdown,
and only pass this inode to devpts_kill_index.
Signed-off-by: Herton R. Krzesinski
Cc:
---
drivers/tty/pty.c | 18 +-
1 file cha
Hi,
recently I got a report of a crash at pty_unix98_shutdown. after analyzing the
issue, I managed to create a small reproducer:
$ cat test.sh
#!/bin/sh
while true; do
find /sys
./dopty
echo 2 > /proc/sys/vm/drop_caches
ps aux
sleep 40
done
$ cat
already
freed inode.
The fix here is to keep a reference on the opened master ptmx inode.
We maintain the inode referenced until the final pty_unix98_shutdown,
and only pass this inode to devpts_kill_index.
Signed-off-by: Herton R. Krzesinski <her...@redhat.com>
Cc: <sta...@vger.kernel.org&
After we acquire the sma->sem_perm lock in exit_sem(), we are protected against
a racing IPC_RMID operation. Also at that point, we are the last user of
sem_undo_list. Therefore it isn't required that we acquire or use ulp->lock.
Signed-off-by: Herton R. Krzesinski
---
ipc/sem.c | 6 +++
}
/* Wait for forked processes to exit */
while (wait(NULL)) {
if (errno == ECHILD)
break;
};
}
end:
return 0;
}
Signed-off-by: Herton R. Krzesinski
Cc: sta...@vger.kernel.org
---
ipc/sem.c
This is a followup series for the patch sent previously, on thread:
"[PATCH] ipc,sem: fix use after free on IPC_RMID after a task using same
semaphore set exits"
The IPC_RMID race fix is split into a single patch with Cc: to stable including
suggestions made previously.
The removal of uneeded
On Mon, Aug 10, 2015 at 09:02:11PM +0200, Manfred Spraul wrote:
> Hi Herton,
>
> On 08/10/2015 05:31 PM, Herton R. Krzesinski wrote:
> >Well without the synchronize_rcu() and with the semid list loop fix I was
> >still
> >able to get issues, and I thought the p
On Mon, Aug 10, 2015 at 09:02:11PM +0200, Manfred Spraul wrote:
Hi Herton,
On 08/10/2015 05:31 PM, Herton R. Krzesinski wrote:
Well without the synchronize_rcu() and with the semid list loop fix I was
still
able to get issues, and I thought the problem is related to racing with
IPC_RMID
)) {
if (errno == ECHILD)
break;
};
}
end:
return 0;
}
Signed-off-by: Herton R. Krzesinski her...@redhat.com
Cc: sta...@vger.kernel.org
---
ipc/sem.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff
This is a followup series for the patch sent previously, on thread:
[PATCH] ipc,sem: fix use after free on IPC_RMID after a task using same
semaphore set exits
The IPC_RMID race fix is split into a single patch with Cc: to stable including
suggestions made previously.
The removal of uneeded
After we acquire the sma-sem_perm lock in exit_sem(), we are protected against
a racing IPC_RMID operation. Also at that point, we are the last user of
sem_undo_list. Therefore it isn't required that we acquire or use ulp-lock.
Signed-off-by: Herton R. Krzesinski her...@redhat.com
---
ipc/sem.c
On Sun, Aug 09, 2015 at 07:49:08PM +0200, Manfred Spraul wrote:
> Hi Herton,
>
(snip)
> >+++ b/ipc/sem.c
> >@@ -2074,17 +2074,24 @@ void exit_sem(struct task_struct *tsk)
> > rcu_read_lock();
> > un = list_entry_rcu(ulp->list_proc.next,
> >
On Sun, Aug 09, 2015 at 07:49:08PM +0200, Manfred Spraul wrote:
Hi Herton,
(snip)
+++ b/ipc/sem.c
@@ -2074,17 +2074,24 @@ void exit_sem(struct task_struct *tsk)
rcu_read_lock();
un = list_entry_rcu(ulp-list_proc.next,
struct
goto end;
}
/* Wait for forked processes to exit */
while (wait(NULL)) {
if (errno == ECHILD)
break;
};
}
end:
return 0;
}
Signed-off-by: Herton R. Krzesinski
---
)
break;
};
}
end:
return 0;
}
Signed-off-by: Herton R. Krzesinski her...@redhat.com
---
ipc/sem.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index bc3d530..35ccddd 100644
v1.11 Mouse [PixArt USB
Optical Mouse] on usb-:00:1a.0-1.6/input0
The quirk was tested by the reporter and it fixed the frequent disconnections
etc.
Signed-off-by: Herton R. Krzesinski
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2
v1.11 Mouse [PixArt USB
Optical Mouse] on usb-:00:1a.0-1.6/input0
The quirk was tested by the reporter and it fixed the frequent disconnections
etc.
Signed-off-by: Herton R. Krzesinski her...@redhat.com
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2
On Mon, May 11, 2015 at 11:35:35AM -0300, Herton R. Krzesinski wrote:
> There is clearly wrong output when mperf monitor runs in MAX_FREQ_SYSFS mode:
> average frequency shows in kHz unit (despite the intended output to be in
> MHz),
> and percentages for C state information a
small issues in the debug output of
max_frequency value in mperf_get_count_freq.
Signed-off-by: Herton R. Krzesinski
---
tools/power/cpupower/utils/idle_monitor/mperf_monitor.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/power/cpupower/utils/idle_monitor
small issues in the debug output of
max_frequency value in mperf_get_count_freq.
Signed-off-by: Herton R. Krzesinski her...@redhat.com
---
tools/power/cpupower/utils/idle_monitor/mperf_monitor.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/power/cpupower/utils
On Mon, May 11, 2015 at 11:35:35AM -0300, Herton R. Krzesinski wrote:
There is clearly wrong output when mperf monitor runs in MAX_FREQ_SYSFS mode:
average frequency shows in kHz unit (despite the intended output to be in
MHz),
and percentages for C state information are all wrong (including
d also release the sock properly, by setting sock = NULL
only if we are returning without error.
Signed-off-by: Herton R. Krzesinski
---
net/rds/tcp_connect.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/rds/tcp_connect.c b/net/rds/tcp_connect.c
index a65ee78..f
Hi,
I got a report of one issue within RDS (after investigation it was a double
free), and I'm sending the fix (patch 3/3) which reporter said it works (no more
WARNING triggered on a specially instrumented kernel). The report/test was done
on a very old kernel (RHEL 5, 2.6.18 based with
Signed-off-by: Herton R. Krzesinski
---
net/rds/threads.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/rds/threads.c b/net/rds/threads.c
index 65eaefc..dc2402e 100644
--- a/net/rds/threads.c
+++ b/net/rds/threads.c
@@ -78,8 +78,7 @@ void rds_connect_complete(struct
re, thus
I can't see the comment being accurate there.
Signed-off-by: Herton R. Krzesinski
---
net/rds/send.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index 2371816..0a64541 100644
--- a/net/rds/send.c
+++ b/net/rds/s
of rds_send_drop_acked: we call rds_send_drop_to
in rds_release and we should have things properly serialized there, thus
I can't see the comment being accurate there.
Signed-off-by: Herton R. Krzesinski her...@redhat.com
---
net/rds/send.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions
Signed-off-by: Herton R. Krzesinski her...@redhat.com
---
net/rds/threads.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/rds/threads.c b/net/rds/threads.c
index 65eaefc..dc2402e 100644
--- a/net/rds/threads.c
+++ b/net/rds/threads.c
@@ -78,8 +78,7 @@ void
Hi,
I got a report of one issue within RDS (after investigation it was a double
free), and I'm sending the fix (patch 3/3) which reporter said it works (no more
WARNING triggered on a specially instrumented kernel). The report/test was done
on a very old kernel (RHEL 5, 2.6.18 based with
release the sock properly, by setting sock = NULL
only if we are returning without error.
Signed-off-by: Herton R. Krzesinski her...@redhat.com
---
net/rds/tcp_connect.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/rds/tcp_connect.c b/net/rds/tcp_connect.c
index a65ee78
52 matches
Mail list logo
