e dongle with id 0 exists). Is
this case feasible from your point of view?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
after
mcam_v4l_release() freed and poisoned them. Is this feasible from your
point of view?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
ct() further down like in iowarrior_release() in
both 'if' branches?
Thank you for your time
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
ace infeasible.
Found by by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Volkov
---
drivers/spi/spi-tegra114.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra11
r your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
concurrently with the
same ent then there is a possibility of a race between the accesses to
ent->cur. In worst case in limit_write new keys wouldn't be added. Is it
feasible from your point of view? If so, is it a benign race or a
serious one?
Thank you for your time.
-- Anton Volkov
though
it should probably be different. Is this race feasible from your point
of view?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
On 15.08.2017 18:58, Oliver Neukum wrote:
Am Dienstag, den 15.08.2017, 16:38 +0300 schrieb Anton Volkov:
On 15.08.2017 16:20, Oliver Neukum wrote:
Am Dienstag, den 15.08.2017, 15:59 +0300 schrieb Anton Volkov:
Hello.
While searching for races in the Linux kernel I've come across
&qu
your point
of view?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
hem changes the ks->cmd_reg_cache it is possible
that both will use the same value though it should be different. Is this
race feasible from your point of view?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
tion feasible from
your point of view? If it is feasible, is it a benign race or something
serious?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
sable_irq()
The value of ucb->stopped may be changed in the midst of 'while' loop
iterations or prevent all of them from happening. Is this feasible from
your point of view? If so, is it a benign race or is it serious?
Thank you for your time.
-- Anton Volkov
Linux Verification
On 15.08.2017 16:20, Oliver Neukum wrote:
Am Dienstag, den 15.08.2017, 15:59 +0300 schrieb Anton Volkov:
Hello.
While searching for races in the Linux kernel I've come across
"drivers/usb/misc/adutux.ko" module. Here is a question that I came up
with while analyzing results.
may then be
assigned an undesirable value and wrong controller may handle messages.
Is this case feasible from your point of view?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
s this case feasible from your point of
view?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
Hello, Omar.
It was a purely theoretical race that had been considered to be possible
in real-life.
Regards,
Anton
On 09.08.2017 01:00, Omar Sandoval wrote:
On Mon, Aug 07, 2017 at 03:37:50PM +0300, Anton Volkov wrote:
The early device registration made possible a race leading to
ug 10, 2017 at 05:57:30PM +0300, Anton Volkov wrote:
Hello.
While searching for races in the Linux kernel I've come across
"drivers/misc/apds990x.ko" module. Here are questions that I came up with
while analyzing results. Lines are given using the info from Linux v4.12.
Conside
suspension status?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
ace infeasible.
Found by by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Volkov
---
drivers/spi/spi-tegra114.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra11
tion feasible from
your point of view? If it is feasible, is it a benign race or something
serious?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
. during the bh1770_resume. Do you know anything
about whether this is intended or this is a bug?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
e->dev is NULL before its initialization in
probe. Thus there might be a NULL pointer dereference in
rcar_dmac_chan_start_xfer while accessing chan->chan.device->dev which
is equal to (&dmac->engine)->dev. Is this possible from your point of view?
Thank you for your time.
-
before its initialization in
isp1760_udc_init_eps and list_empty() tries to access the '->next'
pointer member of the passed parameter.
Is this case possible from your point of view?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
possible to move the device registration a bit further down in the
pc87413_init function?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
This is more of a style-oriented suggestion. This kind of template is
commonly used in other modules.
Regards,
Anton
On 07.08.2017 15:54, Johannes Thumshirn wrote:
On Mon, Aug 07, 2017 at 03:37:50PM +0300, Anton Volkov wrote:
+err_out:
return err;
Any reason you can't jus
won't be feasible in
the future.
Found by by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Volkov
---
v2: Fixed coding style issues
drivers/isdn/hysdn/hysdn_proclog.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --
The early device registration made possible a race leading to allocations
of disks with wrong minors.
This patch moves the device registration further down the loop_init
function to make the race infeasible.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton
The early device registration made possible a race leading to allocations
of disks with wrong minors.
This patch moves the device registration further down the loop_init
function to make the race infeasible.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton
won't be feasible in
the future.
Found by by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Volkov
---
drivers/isdn/hysdn/hysdn_proclog.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/isdn/hysdn/hysdn_proc
you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
cases won't be feasible in
the future.
Found by by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Anton Volkov
---
drivers/isdn/hysdn/hysdn_proclog.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/isdn/
Hello.
While searching for races in the Linux kernel I've come across
"drivers/isdn/hysdn/hysdn.ko" module. Here is a question that I came up
with while analysing results. Lines are given using the info from Linux
v4.12.
In hysdn_proclog.c file in put_log_buffer function a non-standard type
of s
er (spi-tegra114.c: line 1125) or a write
to tspi->def_command1_reg (spi-tegra114.c: line 1121)?
Thank you for your time.
-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru <mailto:avol...@ispras.ru>
33 matches
Mail list logo