Bug 33409

Summary: smb_d_validate: unaligned address errors
Product: [Retired] Red Hat Linux Reporter: Matt Domsch <matt_domsch>
Component: kernelAssignee: Michael K. Johnson <johnsonm>
Status: CLOSED RAWHIDE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: aviro, dledford, john_hull, mark_rusk, sct
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-03-27 23:45:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Matt Domsch 2001-03-27 16:31:33 UTC
Running Florence qa0322, with both kernel-smp-2.4.2-0.1.32.i686 and -
0.1.36, same behavior.
I have smbmounted an NT4 server which contains a mirror of the Red Hat 
rawhide tree.  smbmount with:
smbmount //sd.us.dell.com/d\$ /mnt/sd -o 
username=Matt_Domsch,workgroup=AMERICAS

The smbmount worked just fine, and I could use ls and cd to navigate 
through /mnt/sd as expected.  However, when doing an ls (or a tab 
expansion) in the rawhide/i386/RedHat/RPMS directory, I got the following 
message spewed on the console repeatedly several hundred times:

smb_d_validate: unaligned address f69824a4
smb_d_validate: unaligned address f6982428

The address changes each time.

This message comes from linux/fs/smbfs/cache.c, smb_d_validate():

smb_d_validate(struct dentry *dentry)
{
unsigned long dent_addr = (unsigned long) dentry;
unsigned long align_mask = 0x0F;
if ((dent_addr & ~align_mask) != dent_addr)
     goto bad_align;
}
which returns 0.

Clearly, it's expecting dentry to be paragraph (16-byte) aligned, but it's 
not.  

smb_d_validate() is called from cache.c:smb_dget_fpos().
When it returns 0, then smb_d_getfpos() does additional work.
/* If a pointer is invalid, we search the dentry. */

So, it would appear that the alignment test isn't strictly required, and 
thus shouldn't spew error messages.

Functionally, I could still read files in this directory, and other 
directories exhibited the same problem when running ls.  The number of 
files in the directory may matter, as I get fewer errors if there are few 
files/subdirectories.

Comment 1 Doug Ledford 2001-03-27 20:29:20 UTC
This is better addressed by Al or Stephen since they know the dentry stuff and I
don't.  Cc:ing them so that they can take a look at this.

Comment 2 Stephen Tweedie 2001-03-27 20:54:04 UTC
It's an interaction between some kernel debugging we recently enabled and an
internal debugging check in smbfs.  I'll disable the smbfs check in our
debugging builds to fix this.  The problem is not present in non-debugging
kernel builds.

Comment 3 Stephen Tweedie 2001-03-27 23:45:18 UTC
Fixed in CVS.