On Mon, Sep 20, 2021 at 11:11 AM Ralph Boehme <slow@xxxxxxxxx> wrote: > > Am 20.09.21 um 17:10 schrieb Steve French: > > On Mon, Sep 20, 2021 at 10:03 AM Ralph Boehme <slow@xxxxxxxxx> wrote: > >> > >> Am 20.09.21 um 16:45 schrieb Ralph Boehme: > >>> Am 19.09.21 um 04:13 schrieb Namjae Jeon: > >>>> Use LOOKUP_NO_SYMLINKS flags for default lookup to prohibit the > >>>> middle of symlink component lookup. > >>> > >>> maybe this patch should be squashed with the "ksmbd: remove follow > >>> symlinks support" patch? > >> > >> also, I noticed that the patches are already included in ksmbd-for-next. > >> Did I miss Steve's ack on the ML? > >> > >> I wonder why the patches are already included in ksmbd-for-next without > >> a proper review, I just started to look at the patches and wanted to > >> raise several issues. > > > > I included them at Namjae's request in for-next to allow the automated > > tests to run on them (e.g. the Intel test robot etc.) - those > > automated bots can be useful ... but I had done some review of all of > > them, and detailed review of most, and had run the automated tests > > (buildbot) on them (which passed, even after adding more subtests), > > and the smbtorture tests were also automatically run (it is triggered > > in Namjae's github setup). > > > > Of the 8 patches in for-next, these 3 are the remaining ones that I am > > looking at in more detail now: > > > > 24f0f4fc5f76 ksmbd: use LOOKUP_NO_SYMLINKS flags for default lookup > > 1ec1e6928354 ksmbd: add buffer validation for SMB2_CREATE_CONTEXT > > e2cd5c814442 ksmbd: add validation in smb2_ioctl > > ok, thanks for explaining. > > To be honest, I'm still trying to make sense of the patch workflow. > Hopefully I get there eventually. > > How can I detect if a patch is already reviewed and queued for upstrea > merge, so it's "too late" for me to do a review? It is not too late to do review of any of these 8. Given the importance of security, the more reviews the better. Earliest we would send them (the larger set of 8) upstream would be in a few days. I typically like to have them sit in for-next for 48 hours (although in some cases make exceptions, e.g. for important bug fixes I will shorten this if later in the week so they make it in time for the next rc) -- Thanks, Steve
