drivers/syslog: fix deadlock by reverting part of the changes from b88a8cf39ff1019ad787c4316b22ce29c7daa2dc

[pkarashchenko]

Summary

Revert part of the changes introduced by b88a8cf dues to deadlock in syslog.

Impact

Fix syslog operation

Testing

Pass CI
Tested with custom SAMe70 based board with 2 channels syslog:

1. syslog to console
2. syslog to file on SD card.

[davids5]

@pkarashchenko On looking at this revert and the replacement. At first blush it looks like semaphore based code does exactly what the rmutex added. Would you please enumerate the difference and the root cause of the deadlock?

[pkarashchenko]

@davids5 the deadlock is only caused by changes in drivers/syslog/syslog_device.c.
Initially the syslog take semaphore was returning error code if semaphore is already held (see #6320 (comment))
Other changes are related to introduction of cancellation points in kernel for FLAT build

[davids5]

Let's restore things to a working state and then do a single change for the syslog update.

I was going to suggest splitting this into 2 PR. A revert and a fix for syslog is that what you are saying?

It appears to me that some of the sweeping changes on master have destabilized the project. I would revert all the changes on master and work on an upstream branch until the all the issues are addressed and tested. I would also strongly suggest that future changes like these be done on upstream branches and tested before merging.

@pkarashchenko - you are closer to the problem than I am so I leave it up to you make the call on this.

[pkarashchenko]

Ok. I will split the change into 2 PRs

[pkarashchenko]

@davids5 done. Anyway I was trying to address another part in #6376
I think we need to revert libc related changes anyway and then think about better solution.
I found out that currently we have even bigger gap since in case of FLAT build the _SEM_ macro interface is used also for dynamic memory allocation, so malloc and free become cancellation points. I do not have a solid solution for that, but think that we should not rock the boat with changes like #6320 introducing even more inconsistency.
IMO we need to revert another part of the changes (that I removed from this PR) and spend some time on a design review so then it will be possible to come up with a solid solution.