---
name: "jbd2_journal_try_to_free_buffers"
section: "9"
platform: "linux"
package: "linux-manual-4.9"
version: "4.9.228-1"
release: "Debian 9 (Stretch)"
platforms: ["linux"]
url: "https://new.carta.tech/jbd2_journal_try_to_free_buffers"
---

# jbd2\_journal\_try\_to\_free\_buffers(9)

try to free page buffers.

## NAME

jbd2\_journal\_try\_to\_free\_buffers - try to free page buffers.

## SYNOPSIS

**int jbd2\_journal\_try\_to\_free\_buffers(journal\_t \*** *journal***, struct page \*** *page***, gfp\_t** *gfp\_mask***);**

## ARGUMENTS

*journal*

journal for operation

*page*

to try and free

*gfp\_mask*

we use the mask to detect how hard should we try to release buffers. If \_\_GFP\_DIRECT\_RECLAIM and \_\_GFP\_FS is set, we wait for commit code to release the buffers.

## DESCRIPTION

For all the buffers on this page, if they are fully written out ordered data, move them onto BUF\_CLEAN so **try\_to\_free\_buffers** can reap them.

This function returns non-zero if we wish **try\_to\_free\_buffers** to be called. We do this if the page is releasable by **try\_to\_free\_buffers**. We also do it if the page has locked or dirty buffers and the caller wants us to perform sync or async writeout.

This complicates JBD locking somewhat. We aren't protected by the BKL here. We wish to remove the buffer from its committing or running transaction's -\>t\_datalist via \_\_jbd2\_journal\_unfile\_buffer.

This may \*change\* the value of transaction\_t-\>t\_datalist, so anyone who looks at t\_datalist needs to lock against this function.

Even worse, someone may be doing a jbd2\_journal\_dirty\_data on this buffer. So we need to lock against that. **jbd2\_journal\_dirty\_data** will come out of the lock with the buffer dirty, which makes it ineligible for release here.

Who else is affected by this? hmm... Really the only contender is **do\_get\_write\_access** - it could be looking at the buffer while **journal\_try\_to\_free\_buffer** is changing its state. But that cannot happen because we never reallocate freed data as metadata while the data is part of a transaction. Yes?

Return 0 on failure, 1 on success

## AUTHORS

**Roger Gammans** \<rgammans@computer-surgery.co.uk\>

Author.

**Stephen Tweedie** \<sct@redhat.com\>

Author.

## COPYRIGHT