On Sat, Aug 31, 2019 at 10:44:19AM -0500, Ayush Ranjan wrote:
> There was a broken link for bigalloc. The page
> https://ext4.wiki.kernel.org/index.php/Bigalloc was not migrated into
> the current documentation sources. This patch adds the contents of that
> missing page into the section for Bigall
On Sat, Aug 24, 2019 at 03:24:53PM -0600, Jonathan Corbet wrote:
> I've applied this to the docs tree.
>
> However, Ayush: the patch was rather badly corrupted by your mail client.
> I managed to fix it up, but please in the future verify that you can email
> a patch to yourself and apply it befor
cience and Mathematics
> Business Minor | Gies College of Business
>
>
> On Fri, Aug 23, 2019 at 8:48 AM Theodore Y. Ts'o wrote:
> >
> > On Thu, Aug 15, 2019 at 09:11:51AM -0700, Ayush Ranjan wrote:
> > > This commit aims to fix the following issues in ext
On Thu, Aug 15, 2019 at 09:11:51AM -0700, Ayush Ranjan wrote:
> This commit aims to fix the following issues in ext4 documentation:
> - Flexible block group docs said that the aim was to group block
> metadata together instead of block group metadata.
> - The documentation consistly uses "locatio
On Thu, Aug 15, 2019 at 01:24:35AM +0200, Pavel Machek wrote:
> Burn it with fire!
>
> I mean... people were afraid RDRAND would be backdoored, and you now
> confirm ... it indeed _is_ backdoored? /., here's news for you!
To be fair to AMD, I wouldn't call it a backdoor. Hanlon's razor is
applic
Chandan,
Thanks! I've applied this patch series to the fscrypt git tree.
- Ted
On Sun, Oct 21, 2018 at 05:42:18PM -0700, Matthew Wilcox wrote:
> On Sun, Oct 21, 2018 at 07:14:13PM +0200, Miguel Ojeda wrote:
> > +#if __has_attribute(__fallthrough__)
> > +# define __fallthrough __attribute__((__fallthrough__))
> > +#else
> > +# define __fallthrough
> > +#endif
On Sun, Oct 21, 2018 at 07:14:13PM +0200, Miguel Ojeda wrote:
> From the GCC manual:
>
> fallthrough
>
> The fallthrough attribute with a null statement serves as a
> fallthrough statement. It hints to the compiler that a statement
> that falls through to another case label, or user
Thanks, the update to the documentation looks great!!
I think lockdep_is_held() should be better documented, but that should
be done in the lockdep docs, not the RCU documentation.
- Ted
On Fri, Oct 05, 2018 at 09:40:57PM -0700, Joel Fernandes wrote:
>
> Could you annotate this pointer (sbi->s_qf_names) with __rcu so it can be
> checked by sparse for proper usage? Its also point #16 in the checklist.txt
> RCU document. I enclosed a diff to do this below.
Sure.
> I also saw a bun
On Fri, Oct 05, 2018 at 08:45:40PM -0700, Paul E. McKenney wrote:
>
> Shouldn't the synchronize_rcu() precede the loop doing the kfree()
> calls? Or am I missing something subtle?
No, that was a cut and paste error on my part. I was removing the
rcu_read_unlock() before the kfree loop, and acci
On Thu, Oct 04, 2018 at 05:59:44PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Move the ext4 data structures book to Documentation/filesystems/ext4/
> since the administrative information moved elsewhere.
>
> Signed-off-by: Darrick J. Wong
Thanks, applied and pushed out to the ex
On Fri, Oct 05, 2018 at 04:18:09PM -0700, Joel Fernandes (Google) wrote:
>
> Here are this week's rcu doc updates based on combing through whatisRCU and
> checklists. Hopefully you agree with them. I left several old _bh and _sched
> API references as is, since I don't think its a good idea to rem
On Thu, Oct 04, 2018 at 07:48:31PM -0700, Randy Dunlap wrote:
> Hi Darrick,
>
> I don't see patch 2/2 anywhere (my inbox, email archives)...
Probably because it's moving a lot of files around, so the diffs were 276k.
>
> --
> ~Randy
On Wed, Oct 03, 2018 at 11:41:08PM +0200, Miguel Ojeda wrote:
>
> I forgot to mention that if the definitions were different, it could
> have caused a problem, because your definition wouldn't apply, so your
> 27+ hours of testing wouldn't have mattered :-P Without the #ifndef,
> we would have at
On Wed, Oct 03, 2018 at 01:54:05PM +0200, Miguel Ojeda wrote:
>
> Exactly. And for this case, I simply assumed Stephen wanted a clean
> series to apply on top of the latest next-* tag (same way we base
> stuff on top of -rc*s). Note that this is *not* really a "tree"
> collecting changes/developme
On Wed, Oct 03, 2018 at 12:12:10AM +0200, Miguel Ojeda wrote:
> As I have read, -next is supposed to be a vision of what the merge
> window will look like after merging everything, i.e. ideally -rc1. For
> that to work for files out-of-tree (like these ones, which are not
> maintained by a single t
On Sat, Jul 21, 2018 at 11:19:54AM -0700, Darrick J. Wong wrote:
>
> I pondered that -- maybe leave all the ext4 stuff clustered together,
> but link to it from the actual user/admin guide section?
>
Yeah, I think it makes keep the ext4 (and in the future, xfs, btrfs,
f2fs, etc.) files clustered
On Tue, Jul 10, 2018 at 10:16:42AM -0700, Darrick J. Wong wrote:
> Hi all,
>
> This series converts the existing in-kernel ext4 documentation to rst
> format, links it in with the rest of the kernel's rst documetation, and
> then begins pulling in the contents of the on-disk layout page in the
> w
Darrick has sent in patches to convert the ext4 documentation to use
rst and to be built as part of the full kernel documentation thanks.
In addition to that, he's imported the on-disk documentation from the
ext4 wiki into the kernel sources, so hopefully we can keep it more up
to date.
When I was
20 matches
Mail list logo
