Please read the Dev doc. You need to give describe about what you have done in the commit message. Your words are too general. Regarding the typos, these are just words, you may list the changes in the message so that people can get it easily. Or summarise it. Anyway this is good to me. On Thu, Jul 21, 2022 at 11:09 AM Baoquan He <bhe@xxxxxxxxxx> wrote: > On 07/21/22 at 09:56am, Slark Xiao wrote: > > Fix typo in the comment > > Better tell what's fixed to save reviewers' time: > > Fix typo 'the the' in several places of document. > > Other then this nitpick, looks good to me. > > Reviewed-by: Baoquan He <bhe@xxxxxxxxxx> > > > > > Signed-off-by: Slark Xiao <slark_xiao@xxxxxxx> > > --- > > v2: Add all .rst changes in Documents into 1 single patch > > --- > > Documentation/admin-guide/kdump/vmcoreinfo.rst | 2 +- > > Documentation/bpf/map_cgroup_storage.rst | 4 ++-- > > Documentation/core-api/cpu_hotplug.rst | 2 +- > > Documentation/driver-api/isa.rst | 2 +- > > Documentation/filesystems/caching/backend-api.rst | 2 +- > > Documentation/locking/seqlock.rst | 2 +- > > Documentation/sphinx/cdomain.py | 2 +- > > 7 files changed, 8 insertions(+), 8 deletions(-) > > > > diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst > b/Documentation/admin-guide/kdump/vmcoreinfo.rst > > index 8419019b6a88..6726f439958c 100644 > > --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst > > +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst > > @@ -200,7 +200,7 @@ prb > > > > A pointer to the printk ringbuffer (struct printk_ringbuffer). This > > may be pointing to the static boot ringbuffer or the dynamically > > -allocated ringbuffer, depending on when the the core dump occurred. > > +allocated ringbuffer, depending on when the core dump occurred. > > Used by user-space tools to read the active kernel log buffer. > > > > printk_rb_static > > diff --git a/Documentation/bpf/map_cgroup_storage.rst > b/Documentation/bpf/map_cgroup_storage.rst > > index cab9543017bf..8e5fe532c07e 100644 > > --- a/Documentation/bpf/map_cgroup_storage.rst > > +++ b/Documentation/bpf/map_cgroup_storage.rst > > @@ -31,7 +31,7 @@ The map uses key of type of either ``__u64 > cgroup_inode_id`` or > > }; > > > > ``cgroup_inode_id`` is the inode id of the cgroup directory. > > -``attach_type`` is the the program's attach type. > > +``attach_type`` is the program's attach type. > > > > Linux 5.9 added support for type ``__u64 cgroup_inode_id`` as the key > type. > > When this key type is used, then all attach types of the particular > cgroup and > > @@ -155,7 +155,7 @@ However, the BPF program can still only associate > with one map of each type > > ``BPF_MAP_TYPE_CGROUP_STORAGE`` or more than one > > ``BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE``. > > > > -In all versions, userspace may use the the attach parameters of cgroup > and > > +In all versions, userspace may use the attach parameters of cgroup and > > attach type pair in ``struct bpf_cgroup_storage_key`` as the key to the > BPF map > > APIs to read or update the storage for a given attachment. For Linux 5.9 > > attach type shared storages, only the first value in the struct, cgroup > inode > > diff --git a/Documentation/core-api/cpu_hotplug.rst > b/Documentation/core-api/cpu_hotplug.rst > > index c6f4ba2fb32d..f75778d37488 100644 > > --- a/Documentation/core-api/cpu_hotplug.rst > > +++ b/Documentation/core-api/cpu_hotplug.rst > > @@ -560,7 +560,7 @@ available: > > * cpuhp_state_remove_instance(state, node) > > * cpuhp_state_remove_instance_nocalls(state, node) > > > > -The arguments are the same as for the the cpuhp_state_add_instance*() > > +The arguments are the same as for the cpuhp_state_add_instance*() > > variants above. > > > > The functions differ in the way how the installed callbacks are treated: > > diff --git a/Documentation/driver-api/isa.rst > b/Documentation/driver-api/isa.rst > > index def4a7b690b5..3df1b1696524 100644 > > --- a/Documentation/driver-api/isa.rst > > +++ b/Documentation/driver-api/isa.rst > > @@ -100,7 +100,7 @@ I believe platform_data is available for this, but > if rather not, moving > > the isa_driver pointer to the private struct isa_dev is ofcourse fine as > > well. > > > > -Then, if the the driver did not provide a .match, it matches. If it did, > > +Then, if the driver did not provide a .match, it matches. If it did, > > the driver match() method is called to determine a match. > > > > If it did **not** match, dev->platform_data is reset to indicate this to > > diff --git a/Documentation/filesystems/caching/backend-api.rst > b/Documentation/filesystems/caching/backend-api.rst > > index d7507becf674..3a199fc50828 100644 > > --- a/Documentation/filesystems/caching/backend-api.rst > > +++ b/Documentation/filesystems/caching/backend-api.rst > > @@ -122,7 +122,7 @@ volumes, calling:: > > to tell fscache that a volume has been withdrawn. This waits for all > > outstanding accesses on the volume to complete before returning. > > > > -When the the cache is completely withdrawn, fscache should be notified > by > > +When the cache is completely withdrawn, fscache should be notified by > > calling:: > > > > void fscache_relinquish_cache(struct fscache_cache *cache); > > diff --git a/Documentation/locking/seqlock.rst > b/Documentation/locking/seqlock.rst > > index 64405e5da63e..bfda1a5fecad 100644 > > --- a/Documentation/locking/seqlock.rst > > +++ b/Documentation/locking/seqlock.rst > > @@ -39,7 +39,7 @@ as the writer can invalidate a pointer that the reader > is following. > > Sequence counters (``seqcount_t``) > > ================================== > > > > -This is the the raw counting mechanism, which does not protect against > > +This is the raw counting mechanism, which does not protect against > > multiple writers. Write side critical sections must thus be serialized > > by an external lock. > > > > diff --git a/Documentation/sphinx/cdomain.py > b/Documentation/sphinx/cdomain.py > > index ca8ac9e59ded..a7d1866e72ff 100644 > > --- a/Documentation/sphinx/cdomain.py > > +++ b/Documentation/sphinx/cdomain.py > > @@ -151,7 +151,7 @@ class CObject(Base_CObject): > > def handle_func_like_macro(self, sig, signode): > > u"""Handles signatures of function-like macros. > > > > - If the objtype is 'function' and the the signature ``sig`` is a > > + If the objtype is 'function' and the signature ``sig`` is a > > function-like macro, the name of the macro is returned. > Otherwise > > ``False`` is returned. """ > > > > -- > > 2.25.1 > > > > > > _______________________________________________ > > kexec mailing list > > kexec@xxxxxxxxxxxxxxxxxxx > > http://lists.infradead.org/mailman/listinfo/kexec > > > > -- This is my life,but world of us~~ -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/linux-cachefs
