Internal base file opens using incorrect access mask?

[Volker Lendecke]

On Fri, Nov 22, 2013 at 09:43:57PM +0530, Hemanth Thummala wrote:
> Hi All,
> 
> While debugging an issue, I have come across the code where we try to open
> the base file with access mask zero and  oplock set to none. This is
> getting registered as shared mode lock for the base file.

FYI: The bug is in my inbox. I was just busy with other
stuff today.

> 
> Here is the snippet of code  in create_file_unixpath() which shows this.
> 
> ......
>                 /* Open the base file. */
>                 status = create_file_unixpath(conn, NULL, smb_fname_base,
> 0,===> access mask
>                                               FILE_SHARE_READ
>                                               | FILE_SHARE_WRITE
>                                               | FILE_SHARE_DELETE,
>                                               base_create_disposition,
>                                               0, 0, 0, 0, 0,==> oplock NULL,
> NULL,
>                                               &base_fsp, NULL);
> 
> ......
> 
> 
> 
> Where as in find_oplock_types(), we are filtering out shared mode locks
> from these internal opens using access mask of
> (SYNCHRONIZE_ACCESS|FILE_READ_ATTRIBUTES| FILE_WRITE_ATTRIBUTES).
> 
> Ideally this lock should have been filtered out as internal/stat open in
> find_oplock_types() as suggested by following piece of code.
> 
> ...
>  if (lck->share_modes[i].op_type == NO_OPLOCK &&
>                                 is_stat_open(lck->share_modes[i].access_mask))
> {
>                         /* We ignore stat opens in the table - they
>                            always have NO_OPLOCK and never get or
>                            cause breaks. JRA. */
>                         continue;
>                 }
> 
> ...
> 
> If you check the code for is_stat_open()..
> 
> ....
> bool is_stat_open(uint32 access_mask)
> {
>         return (access_mask &&
>                 ((access_mask & ~(SYNCHRONIZE_ACCESS| FILE_READ_ATTRIBUTES|
>                                   FILE_WRITE_ATTRIBUTES))==0) &&
>                 ((access_mask & (SYNCHRONIZE_ACCESS|FILE_READ_ATTRIBUTES|
>                                  FILE_WRITE_ATTRIBUTES)) != 0));
> }
> 
> ...
> 
> Because of this problem I have seen an oplock test(stream1) failure. Test
> is passed after fixing the access mask.
> Please let me know if my observations are correct.
> 
> I have created a bug 10283 for the same issue.You can find more information
> as part of this bug.
> 
> 
> Thanks,
> Hemanth.

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de