linux-ext4 - Re: [PATCH 12/29] jbd2: Transaction reservation support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130507052200.GA17170@gmail.com>
Date:	Tue, 7 May 2013 13:22:00 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	Jan Kara <jack@...e.cz>
Cc:	Ted Tso <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 12/29] jbd2: Transaction reservation support

On Mon, May 06, 2013 at 02:49:39PM +0200, Jan Kara wrote:
...
> > > +/*
> > >   * start_this_handle: Given a handle, deal with any locking or stalling
> > >   * needed to make sure that there is enough journal space for the handle
> > >   * to begin.  Attach the handle to a transaction and set up the
> > > @@ -151,12 +237,14 @@ static int start_this_handle(journal_t *journal, handle_t *handle,
> > >  			     gfp_t gfp_mask)
> > >  {
> > >  	transaction_t	*transaction, *new_transaction = NULL;
> > > -	tid_t		tid;
> > > -	int		needed, need_to_start;
> > >  	int		nblocks = handle->h_buffer_credits;
> > >  	unsigned long ts = jiffies;
> > >  
> > > -	if (nblocks > journal->j_max_transaction_buffers) {
> > > +	/*
> > > +	 * 1/2 of transaction can be reserved so we can practically handle
> > > +	 * only 1/2 of maximum transaction size per operation
> > > +	 */
> > 
> > Sorry, but I don't understand here why we only reserve 1/2 of maximum
> > transaction size.
>   Well, we allow 1/2 of maximum transaction size to be allocated in already
> reserved handles. So if someone submitted a request for a handle with
> more than 1/2 of maximum transaction size, then we might have to wait for
> reserved handles to be freed. That would be a slight complication in the
> code and it would also possibly introduce livelocking issues - after a
> reserved transaction is freed, someone can reserve a new one before the
> large handle creation request is satisfied. Again this can be solved but
> the complications simply doesn't seem to be worth it.

Fair enough.  Thanks for your explanation.

Regards,
                                                - Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html