On Tue, Jul 10, 2018 at 07:35:23PM -0700, Linus Torvalds wrote:
> This one looked odd to me.
>
> Then I saw 5/42, and it made more sense.
>
> I think the explanation is a bit misleading. Technically correct, but
> not *why* you did it.
Probably should fold these two together, now that reordering
This one looked odd to me.
Then I saw 5/42, and it made more sense.
I think the explanation is a bit misleading. Technically correct, but
not *why* you did it.
Linus
@@ struct file *get_empty_filp(void)
if (unlikely(!f))
return ERR_PTR(-ENOMEM);
- percpu_counter_inc(&nr_files);
f->f_cred = get_cred(cred);
error = security_file_alloc(f);
if (unlikely(error)) {
- file
From: Al Viro
... and rename get_empty_filp() to alloc_empty_file().
dentry_open() gets creds as argument, but the only thing that sees those is
security_file_open() - file->f_cred still ends up with current_cred(). For
almost all callers it's the same thing, but there are several brok
007f6073fc3780() GS:8801c740()
> knlGS:
> [ 402.117062] CS: 0010 DS: ES: CR0: 80050033
> [ 402.955591] CR2: 8801c7060c90 CR3: a88f1000 CR4:
> 000406f0
> [ 403.807725] [] get_empty_filp+0x58/0x1b0
> [ 404.6619
Al Viro writes:
> On Thu, Jan 16, 2014 at 03:45:38PM -0800, Eric W. Biederman wrote:
>>
>> Normally in dentry_open the passed in path is placed on the new filp
>> removing the caller from needing to worry about it. In the rare case
>> that we can not allocate a filp the path is not consumed. N
On Thu, Jan 16, 2014 at 03:45:38PM -0800, Eric W. Biederman wrote:
>
> Normally in dentry_open the passed in path is placed on the new filp
> removing the caller from needing to worry about it. In the rare case
> that we can not allocate a filp the path is not consumed. None of the
> callers of
Normally in dentry_open the passed in path is placed on the new filp
removing the caller from needing to worry about it. In the rare case
that we can not allocate a filp the path is not consumed. None of the
callers of dentry_open call path_put in their error handling when
dentry_open fails so c
> > A little bit of context for this change. We at Google work on a test
> > framework that shows how kernel behaves under memory pressure. In the
> > codepath that I am fixing the syscalls return ENFILE error, but in
> > fact the correct error would be ENOMEM. get_empty_fi
kernel behaves under memory pressure. In the
> codepath that I am fixing the syscalls return ENFILE error, but in
> fact the correct error would be ENOMEM. get_empty_filp() should
> preserve the original error and not to replace all errors with ENFILE.
The trouble is, you are introducin
kernel behaves under memory pressure. In the
> codepath that I am fixing the syscalls return ENFILE error, but in
> fact the correct error would be ENOMEM. get_empty_filp() should
> preserve the original error and not to replace all errors with ENFILE.
Anatol,
I suggest that you rebase
error, but in
fact the correct error would be ENOMEM. get_empty_filp() should
preserve the original error and not to replace all errors with ENFILE.
On Wed, Sep 12, 2012 at 8:11 PM, Anatol Pomozov
wrote:
> Allocating a file structure in function get_empty_filp() might fail because
> of several r
Allocating a file structure in function get_empty_filp() might fail because
of several reasons:
- not enough memory for file structures
- operation is not allowed
- user is over its limit
Currently the function returns NULL in all cases and we loose the exact
reason of the error. All callers
Hi, Al
Do you have some time to review this change? Does it look good?
On Thu, Aug 2, 2012 at 5:47 PM, Anatol Pomozov wrote:
> Allocating a file structure in function get_empty_filp() might fail because
> of several reasons:
> - not enough memory for file structures
> - oper
Hi
On Tue, Aug 21, 2012 at 3:06 AM, Jan Engelhardt wrote:
>
>
> On Wednesday 2012-08-01 20:19, anatol.pomo...@gmail.com wrote:
> >Allocating a file structure in function get_empty_filp() might fail
> > because
> >of several reasons:
> > - not enough memory for f
On Wednesday 2012-08-01 20:19, anatol.pomo...@gmail.com wrote:
>Allocating a file structure in function get_empty_filp() might fail because
>of several reasons:
> - not enough memory for file structures
> - operation is not allowed
> - user is over its limit
>
>Currently the
Allocating a file structure in function get_empty_filp() might fail because
of several reasons:
- not enough memory for file structures
- operation is not allowed
- user is over its limit
Currently the function returns NULL in all cases and we loose the exact
reason of the error. All callers
Hi
Current HEAD contains conflicting changes in fs/pipe.c. I am going to
rebase my patch and resend it.
On Wed, Aug 1, 2012 at 11:34 AM, wrote:
> From: Anatol Pomazau
>
> Allocating a file structure in function get_empty_filp() might fail because
> of several reasons:
> - no
From: Anatol Pomazau
Allocating a file structure in function get_empty_filp() might fail because
of several reasons:
- not enough memory for file structures
- operation is not allowed
- user is over its limit
Currently the function returns NULL in all cases and we loose the exact
reason of
From: Anatol Pomazau
Allocating a file structure in function get_empty_filp() might fail because
of several reasons:
- not enough memory for file structures
- operation is not allowed
- user is over its limit
Currently the function returns NULL in all cases and we loose the exact
reason of
On Tue, 5 Dec 2000, Peter Samuelson wrote:
> The question is whether or not it is worth taking a lock again (with
> that non-zero cost) to achieve the gain of doing the 92-byte memset and
> the atomic_set in parallel with other CPUs. In other words, by locking
> and unlocking twice, you reduce th
[Peter Samuelson]
> > Whether a memset of 92 bytes (on 32-bit arch), plus an
> > atomic_set(), are worth deserializing, I do not know.
[Tigran Aivazian]
> Of course, they are worth it. Actually, I don't understand how can
> you even doubt it?
Clearly we are talking at cross-purposes here. I
On Tue, 5 Dec 2000, Peter Samuelson wrote:
> [Tigran Aivazian]
> > The only reason one could think of was to "hold the lock for as short
> > time as possible" but a minute's thought reveals that such reason is
> > invalid (i.e. one is more likely to waste time spinning on the lock
> > than to save
[Tigran Aivazian]
> The only reason one could think of was to "hold the lock for as short
> time as possible" but a minute's thought reveals that such reason is
> invalid (i.e. one is more likely to waste time spinning on the lock
> than to save it by dropping/retaking it, given the relative dura
Hi Linus,
It is quite clear that dropping and retaking the files_lock in
fs/file_table.c:get_empty_filp() at the label new_one is absolutely
unnecessary. The only reason one could think of was to "hold the lock for
as short time as possible" but a minute's thought reveals that such reason
is inva
Hello All,
I am seeing a bug in get_empty_filp (fs/file_table.c) where
files_stat.nr_free_files is out of sync with respect to the actual number of
elements in free_list.
More precicely, for some reason, free_list became empty (free_list.next and
free_list.prev pointed back to free_list) but
26 matches
Mail list logo
