Re: [RTEMS Project] #1485: Locks while accessing sync_active field in bdbuf library
#1485: Locks while accessing sync_active field in bdbuf library
---+--
Reporter: Oleg.Kravtsov | Owner: sebastian.huber
Type: defect | Status: closed
Priority: normal | Milestone: 4.10.3
Component: filesystem | Version: 4.10
Severity: normal | Resolution: fixed
Keywords: |
---+--
Changes (by Sebastian Huber sebastian.huber@…):
* status: assigned = closed
* resolution: = fixed
Comment:
In [changeset:3b4ca3ab0f99d15794a3eee60b5735f834fd898c/rtems]:
{{{
#!CommitTicketReference repository=rtems
revision=3b4ca3ab0f99d15794a3eee60b5735f834fd898c
bdbuf: Fix race condition with sync active flag
Bug report by Oleg Kravtsov:
In rtems_bdbuf_swapout_processing() function there is the following
lines:
if (bdbuf_cache.sync_active !transfered_buffers)
{
rtems_id sync_requester;
rtems_bdbuf_lock_cache ();
...
}
Here access to bdbuf_cache.sync_active is not protected with anything.
Imagine the following test case:
1. Task1 releases buffer(s) with bdbuf_release_modified() calls;
2. After a while swapout task starts and flushes all buffers;
3. In the end of that swapout flush we are before that part of code, and
assume there is task switching (just before if (bdbuf_cache.sync_active
!transfered_buffers));
4. Some other task (with higher priority) does bdbuf_release_modified
and rtems_bdbuf_syncdev().
This task successfully gets both locks sync and pool (in
rtems_bdbuf_syncdev() function), sets sync_active to true and starts
waiting for RTEMS_BDBUF_TRANSFER_SYNC event with only sync lock got.
5. Task switching happens again and we are again before if
(bdbuf_cache.sync_active !transfered_buffers).
As the result we check sync_active and we come inside that if
statement.
6. The result is that we send RTEMS_BDBUF_TRANSFER_SYNC event! Though
ALL modified messages of that task are not flushed yet!
close #1485
}}}
--
Ticket URL: http://devel.rtems.org/ticket/1485#comment:4
RTEMS Project http://www.rtems.org/
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs
Re: [RTEMS Project] #1485: Locks while accessing sync_active field in bdbuf library
#1485: Locks while accessing sync_active field in bdbuf library
---+--
Reporter: Oleg.Kravtsov | Owner: sebastian.huber
Type: defect | Status: closed
Priority: normal | Milestone: 4.10.3
Component: filesystem | Version: 4.10
Severity: normal | Resolution: fixed
Keywords: |
---+--
Comment (by Sebastian Huber sebastian.huber@…):
In [changeset:f0f2a3dc19e8caddccbb756898b5a413dad9de6a/rtems]:
{{{
#!CommitTicketReference repository=rtems
revision=f0f2a3dc19e8caddccbb756898b5a413dad9de6a
bdbuf: Fix race condition with sync active flag
Bug report by Oleg Kravtsov:
In rtems_bdbuf_swapout_processing() function there is the following
lines:
if (bdbuf_cache.sync_active !transfered_buffers)
{
rtems_id sync_requester;
rtems_bdbuf_lock_cache ();
...
}
Here access to bdbuf_cache.sync_active is not protected with anything.
Imagine the following test case:
1. Task1 releases buffer(s) with bdbuf_release_modified() calls;
2. After a while swapout task starts and flushes all buffers;
3. In the end of that swapout flush we are before that part of code, and
assume there is task switching (just before if (bdbuf_cache.sync_active
!transfered_buffers));
4. Some other task (with higher priority) does bdbuf_release_modified
and rtems_bdbuf_syncdev().
This task successfully gets both locks sync and pool (in
rtems_bdbuf_syncdev() function), sets sync_active to true and starts
waiting for RTEMS_BDBUF_TRANSFER_SYNC event with only sync lock got.
5. Task switching happens again and we are again before if
(bdbuf_cache.sync_active !transfered_buffers).
As the result we check sync_active and we come inside that if
statement.
6. The result is that we send RTEMS_BDBUF_TRANSFER_SYNC event! Though
ALL modified messages of that task are not flushed yet!
close #1485
}}}
--
Ticket URL: http://devel.rtems.org/ticket/1485#comment:5
RTEMS Project http://www.rtems.org/
RTEMS Project
___
bugs mailing list
bugs@rtems.org
http://lists.rtems.org/mailman/listinfo/bugs
Re: [RTEMS Project] #1817: Variable _Thread_Heir is not protected against interrupts
#1817: Variable _Thread_Heir is not protected against interrupts --+-- Reporter: silvah15 | Owner: sebastian.huber Type: defect| Status: closed Priority: normal| Milestone: 4.11 Component: cpukit| Version: 4.10 Severity: normal| Resolution: wontfix Keywords:| --+-- Comment (by sebastian.huber): Thanks for the remainder. I looked now also at 4.10. I don't see a problem here. -- Ticket URL: http://devel.rtems.org/ticket/1817#comment:11 RTEMS Project http://www.rtems.org/ RTEMS Project ___ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
Re: [RTEMS Project] #2129: sync() implementation is dangerous
#2129: sync() implementation is dangerous -+-- Reporter: sebastian.huber | Owner: sebastian.huber Type: defect | Status: assigned Priority: normal | Milestone: 5.0 Component: cpukit | Version: 4.11 Severity: normal | Resolution: Keywords: | -+-- Changes (by sebastian.huber): * milestone: 4.11 = 5.0 Comment: I don't have time and budget to fix this at the moment. -- Ticket URL: http://devel.rtems.org/ticket/2129#comment:4 RTEMS Project http://www.rtems.org/ RTEMS Project ___ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
Re: [RTEMS Project] #1367: Malloc statistics wrong in R4.10
#1367: Malloc statistics wrong in R4.10 +-- Reporter: norume | Owner: sebastian.huber Type: defect | Status: closed Priority: normal | Milestone: 4.11 Component: cpukit | Version: 4.10 Severity: normal | Resolution: fixed Keywords: | +-- Changes (by sebastian.huber): * status: assigned = closed * resolution: = fixed Comment: It is fixed for 4.11: [01557b0c6e723627427195bb33bdfe0b125c70b1/rtems] [2c3c657625f5129e3062058a2c83f0020fd6bab5/rtems] [d006b46df31f6e5f28237fe40eafb135e684b739/rtems] No plans to fix this for 4.10. -- Ticket URL: http://devel.rtems.org/ticket/1367#comment:5 RTEMS Project http://www.rtems.org/ RTEMS Project ___ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
