On Wed, 2024-10-16 at 12:51 +0200, Greg KH wrote: > On Wed, Oct 16, 2024 at 11:22:48AM +0200, Philipp Stanner wrote: > > On Wed, 2024-10-16 at 12:08 +0300, Andy Shevchenko wrote: > > > On Wed, Oct 16, 2024 at 09:25:54AM +0200, Philipp Stanner wrote: > > > > In psnet_open_pf_bar() and snet_open_vf_bar() a string later > > > > passed > > > > to > > > > pcim_iomap_regions() is placed on the stack. Neither > > > > pcim_iomap_regions() nor the functions it calls copy that > > > > string. > > > > > > > > Should the string later ever be used, this, consequently, > > > > causes > > > > undefined behavior since the stack frame will by then have > > > > disappeared. > > > > > > > > Fix the bug by allocating the strings on the heap through > > > > devm_kasprintf(). > > > > > > > --- > > > > > > I haven't found the reason for resending. Can you elaborate here? > > > > Impatience ;p > > > > This is not a v2. > > > > I mean, it's a bug, easy to fix and merge [and it's blocking my > > other > > PCI work, *cough*]. Should contributors wait longer than 8 days > > until > > resending in your opinion? > > 2 weeks is normally the expected response time, but each subsystem > might > have other time limites, the documentation should show those that do. Where do we document that? Regarding resend intervals, the official guide line is contradictory: "You should receive comments within a few weeks (typically 2-3)" <-> "Wait for a minimum of one week before resubmitting or pinging reviewers" <--> "It’s also ok to resend the patch or the patch series after a couple of weeks" https://www.kernel.org/doc/html/latest/process/submitting-patches.html#don-t-get-discouraged-or-impatient We could make the docu more consistent and specify 2 weeks as the minimum time. P. > > While you wait, take the time to review other pending patches for > that > maintainer, that will ensure that your patches move to the top as > they > will be the only ones remaining. > > thanks, > > greg k-h >
