Message ID | 160288261564.3242821.6055291930923876456.stgit@dwillia2-desk3.amr.corp.intel.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 7d18dd75a8afc072aabc77f2a9c3df94cdc53f33 |
Headers | show |
Series | device-dax/kmem: Use struct_size() | expand |
On Fri, Oct 16, 2020 at 2:10 PM Dan Williams <dan.j.williams@intel.com> wrote: > > Link: http://lore.kernel.org/r/CAHk-=wgNTLbvAD8mNTvh+GQyapNWeX20PXhU_+frqEvVq4298w@mail.gmail.com Does that link work for you? Because I can't see it. In fact, I don't see my email at all on lore, even if I see Andrew's email that I answered to: https://lore.kernel.org/mm-commits/20201016024059.Ycwm4GmQ8%25akpm@linux-foundation.org/ but your link gives me "Not Found", and when I search for emails from me on mm-commits I don't see them either. Adding Konstantin just to solve the mystery. Some odd mirroring problem, perhaps? Linus
On Sat, Oct 17, 2020 at 11:39 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Fri, Oct 16, 2020 at 2:10 PM Dan Williams <dan.j.williams@intel.com> wrote: > > > > Link: http://lore.kernel.org/r/CAHk-=wgNTLbvAD8mNTvh+GQyapNWeX20PXhU_+frqEvVq4298w@mail.gmail.com > > Does that link work for you? > > Because I can't see it. > > In fact, I don't see my email at all on lore, even if I see Andrew's > email that I answered to: > > https://lore.kernel.org/mm-commits/20201016024059.Ycwm4GmQ8%25akpm@linux-foundation.org/ > > but your link gives me "Not Found", and when I search for emails from > me on mm-commits I don't see them either. > > Adding Konstantin just to solve the mystery. Some odd mirroring > problem, perhaps? The link did not, and still does not work for me. I was hoping that was a temporary condition until the thread made it out to the mm-commits@ archive on lore, but it never seemed to resolve.
On Sat, Oct 17, 2020 at 11:38:32AM -0700, Linus Torvalds wrote: > > Link: > > http://lore.kernel.org/r/CAHk-=wgNTLbvAD8mNTvh+GQyapNWeX20PXhU_+frqEvVq4298w@mail.gmail.com > > Does that link work for you? > > Because I can't see it. > > In fact, I don't see my email at all on lore, even if I see Andrew's > email that I answered to: > > https://lore.kernel.org/mm-commits/20201016024059.Ycwm4GmQ8%25akpm@linux-foundation.org/ > > but your link gives me "Not Found", and when I search for emails from > me on mm-commits I don't see them either. > > Adding Konstantin just to solve the mystery. Some odd mirroring > problem, perhaps? I don't really have any insights here, unfortunately. Judging from conversations I see on IRC, I gather that vger had another outage earlier today, so chances are that your email will eventually get delivered and will start showing up on lore.kernel.org. Right now, we have no record of a message with that message-id traversing archiver.kernel.org. (Vger is historically maintained by a different set of people from the rest of kernel.org, so I have no access or visibility to trace situations like that. If folks wanted to review the current arrangement, I'm sure the Linux Foundation would be willing to roll it into the rest of the infrastructure to be managed by the same LF IT team. I don't want to impose anything here, though, so this would need to be initiated by the community and with full agreement of current vger administrators.) -K
On Sat, 17 Oct 2020 13:54:08 -0700 Dan Williams <dan.j.williams@intel.com> wrote: > On Sat, Oct 17, 2020 at 11:39 AM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > On Fri, Oct 16, 2020 at 2:10 PM Dan Williams <dan.j.williams@intel.com> wrote: > > > > > > Link: http://lore.kernel.org/r/CAHk-=wgNTLbvAD8mNTvh+GQyapNWeX20PXhU_+frqEvVq4298w@mail.gmail.com > > > > Does that link work for you? > > > > Because I can't see it. > > > > In fact, I don't see my email at all on lore, even if I see Andrew's > > email that I answered to: > > > > https://lore.kernel.org/mm-commits/20201016024059.Ycwm4GmQ8%25akpm@linux-foundation.org/ > > > > but your link gives me "Not Found", and when I search for emails from > > me on mm-commits I don't see them either. > > > > Adding Konstantin just to solve the mystery. Some odd mirroring > > problem, perhaps? > > The link did not, and still does not work for me. I was hoping that > was a temporary condition until the thread made it out to the > mm-commits@ archive on lore, but it never seemed to resolve. mm-commits is writeable-only-by-akpm. That's how davem originally set it up, not sure why. I don't think this has caused difficulty in the past, but it is a bit odd. Dave, can we please turn it into a regularly managed list? Thanks.
On Sat, Oct 17, 2020 at 2:43 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > mm-commits is writeable-only-by-akpm. Ahh. That's fine, it's only inconvenient for these kinds of "people replied to patches". It's not necessarily just me either - people reply with Ack's etc, and the fact that the list is write-by-akpm-only them means that "b4" etc won't see it. Normally I pick those things up personally, though, so apart from the whole lore link issue that's not necessarily a big deal either. And afaik, this is the first time somebody actually tried to refer to a lore link and it failed. Often you cc other lists as well, but that tends to be a patch-by-patch thing, so it's not reliable. Linus
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c index b4368c5b6a0c..403ec42472d1 100644 --- a/drivers/dax/kmem.c +++ b/drivers/dax/kmem.c @@ -61,7 +61,7 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax) return -EINVAL; } - data = kzalloc(sizeof(*data) + sizeof(struct resource *) * dev_dax->nr_range, GFP_KERNEL); + data = kzalloc(struct_size(data, res, dev_dax->nr_range), GFP_KERNEL); if (!data) return -ENOMEM;
Linus notes the kernel has had a nice helper for the 'size of struct with variable array member at the end' operation for a couple years now, use it. Link: http://lore.kernel.org/r/CAHk-=wgNTLbvAD8mNTvh+GQyapNWeX20PXhU_+frqEvVq4298w@mail.gmail.com Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> --- drivers/dax/kmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)