https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4232 Lustre <p>Problems in <a href="https://jira.whamcloud.com/browse/LU-4226" title="MDS unable to locate swabbed FID SEQ in FLDB" class="issue-link" data-issue-key="LU-4226"><del>LU-4226</del></a> indicate that the MDS allows incoming file creates with bad FIDs to proceed, even though the FID SEQ is not in a valid range. These requests should be refused by the server.</p> <p>The source of the invalid SEQ may be related to PPC clients not swabbing the allocated SEQ range correctly, but that is the topic of another bug. </p> LU-4232

MDT and OST should validate incoming FIDs belong to local target

Improvement Critical Open Unresolved WC Triage Andreas Dilger medium ppc Fri, 8 Nov 2013 18:02:37 +0000 Wed, 11 Aug 2021 18:04:02 +0000 Lustre 2.1.6 Lustre 2.6.0 0 4 <p><a href="https://jira.whamcloud.com/browse/LU-4233" title="Verify PPC FID swabbed correctly during create. " class="issue-link" data-issue-key="LU-4233">LU-4233</a> was filed for the PPC client swabbing issue. </p> <p>It may be that this checking has already been implemented for 2.4+ MDS due to local/remote checking for DNE. Having a sanity.sh test using a new <tt>OBD_FAIL_ | CFS_FAIL_RAND</tt> that randomly injects a bad FID SEQ on the client (maybe in mdc_pack_op_data()?) and has it try a bunch of different operations (e.g. by running racer) would be useful. </p> <p>The FID SEQ should also be verified for OST operations. This was not possible with FID_SEQ_OSD_MDT0 previously, but is possible for FID_SEQ_IDIF and FID_SEQ_NORMAL objects. That is more motivation for <a href="http://review.whamcloud.com/7053" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7053</a> from <a href="https://jira.whamcloud.com/browse/LU-3569" title="Use real OST index as ostid_to_fid() parameter instead of always &quot;0&quot;" class="issue-link" data-issue-key="LU-3569"><del>LU-3569</del></a> to be landed. </p> <p>At a minimum this needs an audit of the MDT and OST code to verify that incoming code paths (in particular create) has valid FIDs for the target. It may be that 2.4+ already has sufficient checking for this, in which case only a test is needed that forces a client to try and create some files with invalid FIDs (which should fail).</p> <p>Mike, I think that this is already done for OST object FIDs/ostids, and I <em>think</em> that it is done for MDT object FIDs also. Could you please check the code and confirm? If yes, then this bug can be closed.</p> <p>Andreas, there is check fid_is_sane() for incoming FIDs on MDT, this should prevent the processing of swabbed FIDs. Meanwhile I am not sure about original meaning for this ticket, it says 'incoming FIDs belong to local target', does that mean FID must always be local, i.e. all incoming FIDs must be not remote objects?</p> <p>Mike, the original problem seen was that with older PPC clients they did not swab the incoming SEQ properly and then generated FIDs with bad SEQ to the MDS. If the MDS checked that the FID was local it would have returned an error to the client and we would have noticed and fixed that easily. </p> <p>yes, and fid_is_sane should catch such FIDs or you mean that doesn't help because only seq is no swabbed and looks like some other big sequence?<br/> If we need to ensure FID is local for that particular MDT it would be more complex. For this we need to ask FLDB or get lu_object by that FID and check it is local.</p> <p>Would it make sense to open a new ticket for the more complex work you mention and close this ticket?</p> <p>Mike, I thought Di implemented a local FLDB cache, so doing one FLDB lookup per RPC to verify the FID is local should be ok?</p> <p>Jodi, I don't know if there is a benefit to close this ticket and open a new one? Are there any patches landed with this ticket? If not, it could just be moved to 2.7. I think the critical checks of this ticket are already present in 2.6, landed under other tickets. </p> <p>Also note that fid_is_sane() only checks if a FID <em>might</em> be OK, but will let almost any value through, and is hardly a check at all. It does nothing to verify if the FID belongs to the client using it to create a new file, or if it belongs to the local server node. </p> Related LU-4226 LU-3569 LU-5369 LU-4233 Development Rank 1|hzw8h3: Rank (Obsolete) 11525