[MDEV-15584] Linux - use O_TMPFILE for create_temp_file Created: 2018-03-16  Updated: 2021-09-14  Resolved: 2018-06-04

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.3
Fix Version/s: 10.4.0

Type: Bug Priority: Major
Reporter: Sergey Vojtovich Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: contribution, foundation

Issue Links:
Problem/Incident
causes MDEV-26601 Incorrect use of O_TMPFILE Closed
Relates
relates to MDEV-15587 AES test fails, segfaults in EVP_Ciph... Closed

 Description   

This pr, branched from #639, uses the Linux the open(2) O_TMPFILE option to create an already delete temporary.

With this option we don't need to delete the created file and for convenience we don't use my_register_filename to allocate string copies of names (as an aside - is this really still needed in the code? Seems only there for debugging).

As such we don't need to dup in innobase_mysql_tmpfile.

Like the my_register_filename, we do increase statistic counters like #657.

If the open(O_TMPFILE) fails, unsupported filesystem for instance, fall back to mk{,o}stemp



 Comments   
Comment by Marko Mäkelä [ 2019-04-08 ]

This contribution causes open(2) to be invoked with a potentially NULL first argument. Because the system call wrapper function is declared with nonnull first argument, this allows GCC 8 to assume that the parameter dir is actually nonnull, and to optimize away some necessary code in a later code path.

Similar to MDEV-15587, the fix is to ensure that functions declared with nonnull are not being called with NULL parameters.

This bug caused a crash in mysqlbinlog, which was invoking create_temp_file() with the argument dir=NULL. The affected test was binlog.binlog_mysqlbinlog_base64. It would display the following message before crashing:

mariadb-10.4.4

mysqlbinlog: O_TMPFILE is not supported on (null) (disabling future attempts)
Segmentation fault

Comment by Marko Mäkelä [ 2019-04-08 ]

I pushed a fix of the regression to 10.4. It will be in MariaDB 10.4.5.

Generated at Thu Feb 08 08:22:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.